Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Describe the backend architecture and required changes.

  2. Describe the webapp changes required.

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

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

Out:

  • CLI changes

  • chat-facing administration of channel moderation settings

BACKGROUND READING

  1. Channel Moderation Settings feature specifcationspecification

  2. High fidelity designs

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“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 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 necessary concept because previously there was no ongoing “inheritance”-style relationship between schemes. Not there is (at least temporarily) as described below.

SPECIFICATIONS

High-level Architecture

...

  • add a channel-scoped permission to a team scheme with an associated team

  • remove a channel-scoped permissions from a team scheme with an associated team

  • add a team to a team scheme

  • remove a team from a team scheme


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

Permissions

New permission:

...

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 schema changes.

...

The new Roles records that are created will be updated to match the Permissions value from the higher-scoped scheme. Question: does it already copy the permissions from the 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” 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 ability to send @here, @all, and @channel must have access controlled by the new use_channel_mentions permission.

...

Configuration

None needed. Question: will channel moderation be experimental?

Frontend

  • Design of channel moderation UI in the system console TBD.

  • 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.

...