OVERVIEW
This specification outlines how to achieve “channel moderation” feature in Mattermost. Channel moderation provides system administrators with toggles to enable and disable various channel-level features including:
Making a channel read-only to everyone except channel admins
Disallowing adding a removing members by everyone except channel admins
Disabling @all, @channel, @here for everyone except channel admins
GOALS
Describe the backend architecture and required changes.
Describe the (general) webapp changes required.
SCOPE
This document will describe the backend approach including new API endpoints required and the changes that will occur in the database.
It will generally describe the webapp changes required.
It will not outline mobile (React Native) changes.
BACKGROUND READING
TERMINOLOGY
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119
SPECIFICATIONS
High-level Architecture
The Channel Moderation feature leverages the existing permissions system to create a “Channel Override Scheme” for each channel for which channel moderation is enabled.
Enabling moderation for a given channel creates a record in the Schemes table with a Scope of “channel” and also creates two new Roles records. The new Roles records initially copy their Permissions value from the higher-scoped scheme (system scheme or team scheme).
Permissions associated to the new scheme’s Guest and Member roles can be edited to affect the given channel, allowing for custom permission for the given channel.
If moderation is turned off for a given channel the Schemes record is deleted and the channel members automatically go back to using the permissions as configured on the higher-scoped scheme.
Any channel-scoped permissions that are not exposed in the channel moderation UI but are configurable in the system schemes and team schemes UI must be kept in sync with the channel scheme, namely:
use_slash_commands
manage_public_channel_properties
manage_private_channel_properties
… (TODO)
Schema
There are no schema changes.
REST API
When the “enable channel moderation” toggle is flipped on a POST request is made to /api/v4/schemes (existing) to create the channel scheme.
The new roles records that are created will be updated to match the permissions from the higher-scoped scheme. Note that this may already be existing behaviour.
Question: Can the DefaultChannelAdminRole id be set to the value of the higher-scoped scheme’s role? Is that feasible and helpful because it decreases the number of permissions that need to be updated or does it add complexity?
When the “enable channel moderation” toggle is flipped off a DELETE request is made to /api/v4/schemes/:scheme_id.
Question: Does the delete scheme API endpoint cleanup orphaned Roles records?
CLI
TBD
Configuration
None needed.
Frontend
A new toggle UI element must be added to the channel details view to create the channel scheme. UI still pending.
UI also still pending for the actual channel moderation block that is displayed once channel moderation is enabled.
Performance
There will be a performance degradation to updating channel-scoped permissions on system and channel schemes because they must be also updated on all channel schemes, which is likely to be slow because permissions are saved as a string array in the database.
Plugins
TBD
CREDITS
Give credit here to anyone who helped you write the spec or provided feedback to improve it.