...

• Making a channel “read-only” (or the inverse, enabling posting) for members and guests

• Allowing or disallowing members and guest from adding and removing other members

• Allowing or disallowing members and guests from using channel mentions (@all, @channel, @here)

GOALS

1. Describe the backend architecture and required changes.

2. Describe the webapp changes.

3. Describe the mobile (React Native) app changes.

SCOPE

In:

• exposing channel moderation in the system console in the channel details view

• updates to the UI (webapp and mobile) to apply the create_post permission

• updates to the UI (webapp and mobile) to apply the new use_channel_mentions permission

...

“channel moderation”: although this term is used throughout this document it may not end up being the customer-facing terminology used as some find it confusing vs something compared to an alternative that describes that permissions are being overridden.

“higher-scoped scheme”: the system scheme or team scheme from which the channel derives all of its permissions in the absence of a channel scheme. This is a newly necessary term/concept because previously there was no ongoing “inheritance”inheritance-style relationship between schemes.

“channel mentions”: the at-mentions “@all”, “@here”, and “@channel”.

“channel scheme”: a Schemes record with a Type value of channel. It overrides the permissions for given channels much like a team scheme overrides the permissions for a given team.

SPECIFICATIONS

High-level Architecture

The Channel Moderation channel moderation feature leverages the existing permissions system to create a channel scheme for each channel for which channel moderation is enabled. Enabling moderation for a given channel creates a record The channel scheme causes permissions to be overridden and configurable for the channel.

More technically, a record is created in the Schemes table with a Scope value channel. It also creates two Three new Roles records are also created and their Id values used to set the new Schemes record’s DefaultChannelAdminRole, DefaultChannelUserRole, and DefaultChannelGuestRoles. The new Roles records initially copy their Permissions value from the higher-scoped schemescheme’s associated Roles records. A set of the permissions associated to the new channel scheme’s guest and member can subsequently be edited to provide users with those roles in that channel different permissions—in the context of the channel—than the configured on the higher-scoped schemes

Guest and member Roles records Permissions values are then updated as desired to change the permissions of the specific channel associated to the channel scheme.

If moderation is disabled for a channel, the channel the channel’s associated Schemes record is deleted and the channel members and guests automatically revert having to using the permissions as configured on the higher-scoped scheme.

...

Relationship between a channel

...

scheme and its higher-scoped scheme

Per the permissions system design, a channel scheme completely overrides all channel-scoped permissions for on the given associated channel(s). This means that if there are permissions that are not exposed by channel moderation, admins will expect those permissions to be configured as per the higher-scoped scheme—lest permissions be overridden behind the scenes on the channel scheme without the knowledge of admins.

Since there is no “inheritance” as such between the schemes, all channel-scoped permissions that are not modified by the channel moderation UI must be are updated on the channel scheme upon each change to the higher-scoped scheme.

Channel-scoped permissions are the only type of permissions that can be used by channel -scoped schemes and , thus they’re the only ones permissions modifiable by channel moderation settings, and also the only ones permissions that must be updated per changes to the higher-scoped scheme.

...

The following actions trigger synchronization of permissions from high-scoped schemes to channel schemes:

Updates to all channel schemes:

...

• add a channel-scoped permission to a team scheme with (if it has an associated team)

• remove a channel-scoped permissions from a team scheme with (if it has an associated team)

• add a team to a team scheme

• remove a team from a team scheme

• delete a team scheme

• create a team scheme (if it has an associated team)

Question: Is updating permissions from higher-scoped schemes' roles to channel schemes' roles compatible and feasible with this synchronization compatible with the plan for the future custom roles feature?

Permissions

New permission:

A new permission named use_channel_mentions has been is created, without which users are not able to use @all, @channel, and @herechannel mentions.

Guest role permissions modified by channel moderation:

edit_post
delete_post
add_reaction/remove_reaction
create_post
use_channel_mentions

Member role permissions modified by channel moderation:

manage_public_channel_members/manage_private_channel_members
edit_post
edit_others_posts
delete_post
delete_others_posts
add_reaction/remove_reaction
create_post
use_channel_mentions

All other channel-scoped permissions on channel schemes' associated Rolesrecords Guest, member, and channel admin role permissions that are kept synchronized with their the higher-scoped scheme (some are not exposed via the UI but they will be synchronized none-the-less to maintain parity with the API rather than a single client’s UI):

manage_public_channel_properties
manage_private_channel_properties
delete_public_channel
delete_private_channel
remove_others_reactions
upload_file
create_post_public
create_post_ephemeral
manage_channel_roles
read_channel

Question: Do we need to expose create_post and use_channel_mentions in the system and team schemes UI?

Schema

There are no No schema changes.

REST API

• When “enable channel moderation” (

...

• see design for exact wording) is toggled on, a POST request is made to the existing API endpoint /api/v4/schemes to create the channel scheme.

The new Roles records that are created will be updated to match the Permissions value from the higher-scoped scheme (as described in the high-level architecture above).

Question: does it the API already copy the permissions from the previous “previous” scheme? If so, then no update is required. If not, can we consider making that a permanent part of the create team and channel scheme API behaviour, avoiding a separate update?

• When “enable channel moderation” is toggled off, a DELETE request is made to /api/v4/schemes/:scheme_id. 

Question: Does the delete scheme API endpoint cleanup orphaned Roles records? If not does it make sense to make that a permanent part of the API behaviour?

• The

...

• API to create channel mentions must have access controlled by the new use_channel_mentions permission.

CLI

Out of scope.

Configuration

None needed unless channel moderation is experimental.

Question: will channel moderation be experimental?

Frontend

...

Webapp only

• TBD. Designs for the channel moderation UI in the system console TBD.is pending.

Mobile and Webapp

• Preventing posting based on permissions (rather than it currently being prevented based on the experimental done with the “experimental read-only town square square” feature) must be implemented throughout the UI.

• Preventing access to @here, @all, @channel must be controlled by the new use_ channel _ mentions permission.

Mobile

• Preventing posting based on permissions (rather than it currently being prevented based on the experimental read-only town square feature) must be implemented throughout the UI.

• Preventing access to @here, @all, @channel must be controlled by the new use_channel_mentions permission.

...