[WIP] UX Spec: ABAC Phase 2 (Channel Admin Controls)

Overview

This document outlines the user experience for Channel Admins to configure Attribute-Based Access Controls (ABAC) at the channel level via the Channel Settings modal in Mattermost.

This feature (Phase 2 of Attribute-Based Channel Access) builds on the Phase 1 foundations, enabling the set up of channel-specific access rules using existing user attributes, outside of the system console.

The goal is to allow Channel Admins to easily restrict channel membership based on user attributes while respecting system-wide policies and ensuring a seamless, accessible experience.

Goals

Empower Channel Admins: Allow Channel Admins to self-serve access control for their channels (within limits set by System Admins), reducing reliance on IT for managing confidential discussions.
Transparency and Confidence: Provide immediate feedback and testing tools so admins understand who would have access under the rules.
Non-Disruptive & Safe Configuration: Ensure that Channel Admins cannot inadvertently lock themselves (or all users) out of their own channels, and handle rule changes in a way that clearly communicates any impact (such as members being removed).
Consistency with Global Policies: Channel-level rules should add to (not override) any organization-wide access policies set by System Admins. The UI should reflect any global restrictions in effect so Channel Admins have the full context.

Channel Settings Modal

The Channel Settings modal will include a new tab called “Access Control” dedicated to channel-level access rules.

This tab is visible only to users with the necessary permissions, only for private channels, and only if the ABAC feature is enabled system-wide by a System Admin.

The UI will be presented in a basic, table-like form to list and manage simple attribute rules (Basic Mode), with no advanced policy syntax or code editor.

There will be no way to create or edit an Access Policy from the Channel Settings modal.

Basic mode editor

Rule creation and editing in this UI should be identical to how it works in the Basic mode editor available in the policy editor of the System Console.

We do need to provide a way for channel admins to preview who matches the current rules. This can also be identical to the system console and be triggered via a Test Access Rules button below the rules list. The purpose is to let the admin verify the outcome of the rules before saving. The test logic should filter out users on the basis of any access policy applied in the System Console + the custom rules configured by the channel admin.

Global Policy Indicator (if applicable): If any system-level access policies affect this channel (set by System Admin in Phase 1), the UI should show them. This would be informational (in read-only form or a greyed-out rule” row) to let the Channel Admin know there are additional constraints beyond what they configure. Channel Admins cannot edit or remove these global rules from here. The rules they add will be additive to these policies – meaning a user must satisfy both the global and channel-specific conditions to access.

Validation on Add: On attempting to add/save, the system validates the rule:

If the rule would exclude the Channel Admin themselves, prevent the action. An error message is shown (e.g., “You cannot set this rule because it would remove you from the channel.”). The admin must adjust or cancel the rule. (The admin’s own user attributes are checked behind the scenes against the new condition.)
If any required fields are blank or invalid (no attribute selected, or no value entered), the UI will not allow saving (highlight the empty fields with a warning or show a message “Please select an attribute and value”).
If a similar or duplicate rule already exists, either disallow the duplicate or merge them. For example, if an admin tries to add “Department = Engineering” when one already exists, the UI can highlight the conflict: “Rule already exists.”

Rules Applied: Once saved, any updates to the rules should trigger a re-sync of channel membership immediately. Any current members who do not meet the new rules will now be removed from the channel (with appropriate system notifications or messages as needed). The Channel Admin who set the rule is guaranteed to still be in the channel (due to the self-exclusion check).

If the toggle for Auto-adding members based on access rules is enabled, users should also be immediately added to the channel after saving if applicable.
The channel’s join behavior also updates immediately: going forward, only users whose attributes satisfy the rule can join or be invited.

Edge Case – All Rules Removed: If the admin deletes all rules, and there is no system level access policy applied to the channel, the channel returns to a standard access state. In this cases, the toggle for Auto-adding members based on access rules cannot be enabled and is auto-disabled.

Validation and Error Handling

Robust validation is critical to prevent misconfigurations and to guide Channel Admins while they define rules. Below are key validation rules and how the UI handles errors or edge conditions:

Self-Exclusion Block: The system must prevent Channel Admins from excluding themselves with any rule. This is a hard validation rule. If the admin’s own user attributes do not satisfy a new or edited rule, the UI should immediately flag this on Save.
If multiple channel admins exist, ideally none of them should be excluded; however, the check will only be against the current user making changes (to avoid confusion and because they might not know another admin’s attributes).
Empty or Invalid Inputs: If the admin clicks “Add rule” but does not complete the fields, or tries to save an empty value, the UI will highlight the missing information.
Conflicting Rules: In Basic Mode, Channel Admins are not expected to create conflicting rules (since all rules are combined with AND logic, they can only narrow access further). However, if the admin somehow adds two rules that can never be satisfied together (e.g., Custom rule configured: Department = Engineering, and rule from access policy: Department = Sales, a user cannot be in two departments at once), the result is that no user can satisfy both. The UI should warn “No user can satisfy all these rules – please adjust or remove conflicting rules.” This can be detected if the admin adds a rule on the same attribute with a different value while another exists.