...

For example, say the higher-scoped scheme removes the “Archive Channels” permission (technically the delete_public_channel and delete_private_channel permissions). That permission is not configurable on the channel scheme given the current UI, so the system admin would not expect that permission to remain present for all channel that have moderation enabled, in spite of the fact that the permissions architecture would leave it present on the channel scheme by default. So we must have code that removes that permission from the channel scheme for all affected channels.

Since there is no “inheritance” as such between schemes, all channel-scoped permissions that are not modified by the channel moderation UI 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 schemes, thus they’re the only permissions modifiable by channel moderation settings, and the only 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 the system scheme

• remove a channel-scoped permission from the system scheme

Updates to all of the channel schemes for a given team:

...

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

...

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

...

add a team to a team scheme

...

remove a team from a team scheme

...

delete a team scheme

...

If a channel has a scheme, the set of moderated permissions on that channel scheme will completely override the permission of the higher scoped scheme. However, non-moderated permissions will be ignored on the channel scheme and instead be read from the higher-scoped scheme.

Permissions

New permission:

...

create_post_public
create_post_ephemeral
delete_post/delete_others_posts (exposed in schemes UI)
edit_post/edit_others_posts (exposed in schemes UI)
manage_channel_roles
manage_public_channel_properties/manage_private_channel_properties (exposed in schemes UI)
delete_public_channel/delete_private_channel (exposed in schemes UI)
read_channel
remove_others_reactions
upload_file

Schema

No schema changes unless the performance of updating non-moderated channel-scoped permissions on the higher-scoped schemes is problematic, in which case we can see if we can improve the update performance by changing how permissions are stored. Currently permissions are stored as a space-separated string in the Permissions column of the Roles table. We could test migrating them to a join table, something like this:

After that change, adding and removing permissions from roles may get faster because—although it would still need to be done once per role (i.e. 3x) per affected channel per affected permission—at least the string parsing could be eliminated and indexes would be available.

REST API

• A new endpoint to get the channel moderation matrix. For example, to display the matrix as shown in the configuration from the high-fidelity mockups, the API endpoint GET /api/v4/channels/:channel_id/moderations returns the following:

[{
        "name": "create_post",
        "roles": {
            "guests": {
                "value": false,
                "enabled": true
            },
            "members": {
                "value": false,
                "enabled": true
            }
        }
    },
    {
        "name": "postcreate_reactions",
        "roles": {
            "guests": {
                "value": false,
                "enabled": false
            },
            "members": {
                "value": true,
                "enabled": true
            }
        }
    },
    {
        "name": "manage_members",
        "roles": {
            "members": {
                "value": true,
                "enabled": true
            }
        }
    }, 
    {
        "name": "use_channel_mentions",
        "roles": {
            "guests": {
                "value": false,
                "enabled": true
            },
            "members": {
                "value": true,
                "enabled": true
            }
        }
    }
]

• A new endpoint to update the channel moderation configuration. For example, to re-add the ability for only members to create posts the API endpoint POST PUT /api/v4/channels/:channel_id/moderations/patch would receive:

[{
    "name": "create_post",
    "roles": {
        "members": true
    }
}]

• Update the create post flow (for example in mattermost-server/app/notifications.go) to restrict access to channel mention notifications to those with the use_channel_mentions permission.

• Update the PUT /api/v4/schemes/:scheme_id/patch endpoint to validate that the requested permission change is permitted if it is attempted against a role that is used by a channel-scoped scheme. The role can only be less permissive than the permissions on the higher-scoped scheme.

CLI

Out of scope.

Configuration

...

• Prevent posting based on the create_post permissions.

• Preventing access to channel mentions based on the use_channel_mentions permission.

Performance

The synchronization of permissions (as described above) will cause There may be a performance degradation when updating channel-scoped permissions on the system scheme or on team schemes. The permissions marked (exposed in schemes UI) in the list of permissions that must be replicated from the Permissions section of this document are those that will cause the scheme UI in the webapp to be slower upon editing and saving. The still affect direct API calls.The performance impact of the replication of permissions from the higher-scoped schemes to the channel schemes can be tweaked by optionally changing how permissions are stored in Mattermost as described in the Schema section of this documentquerying the presence of non-moderated, channel-scoped permissions.

Plugins

Out of scope.

CREDITS

Thanks to Arturo, Catalin, Dennis, George, Scott, Hossein, and Scott Farhan for bouncing some of these ideas around with me.