-
Notifications
You must be signed in to change notification settings - Fork 619
[MM-68497] add docs for membership policies for public channels #8923
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
isacikgoz
wants to merge
5
commits into
master
Choose a base branch
from
MM-68497
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+89
−40
Open
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
28217c5
add docs for membership policies for public channels
isacikgoz a482161
Apply suggestions from code review
isacikgoz 85649aa
fix: apply CodeRabbit auto-fixes
coderabbitai[bot] 63660ff
Revert source code changes to sphinx_inline_tabs/directive.py
cursoragent fc6130a
Merge remote-tracking branch 'origin/master' into MM-68497
cursoragent File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,30 +4,35 @@ Channel-specific access rules | |
| .. include:: ../../../_static/badges/entry-adv.rst | ||
| :start-after: :nosearch: | ||
|
|
||
| Channel and Team Admins can self-manage access controls for their private channels directly through the Channel Settings modal, without requiring System Admin intervention. For organization-wide policies created by System Admins, see :doc:`System-wide attribute-based access policies </administration-guide/manage/admin/abac-system-wide-policies>`. For team-scoped policies that apply rules across multiple private channels within a team, see :doc:`Team-level channel membership policies </administration-guide/manage/admin/abac-team-channel-policies>`. | ||
| Channel and Team Admins can self-manage access controls for their channels directly through the Channel Settings modal, without requiring System Admin intervention. For organization-wide policies created by System Admins, see :doc:`System-wide attribute-based access policies </administration-guide/manage/admin/abac-system-wide-policies>`. For team-scoped policies that apply rules across multiple channels within a team, see :doc:`Team-level channel membership policies </administration-guide/manage/admin/abac-team-channel-policies>`. | ||
|
|
||
| Each ABAC channel access policy has an explicit active state that determines whether the policy will automatically add users who meet the policy's criteria but are not yet channel members. When a policy is applied to a channel, the policy's rules are always enforced to remove members who no longer meet the required attribute rules, regardless of the active state. | ||
| From Mattermost v11.8, channel access rules can be applied to **both private and public channels**. The two channel types behave differently under ABAC: | ||
|
|
||
| - **Private channels** are hard-gated. Non-matching members are removed during synchronization, and only matching users can be added or invited. | ||
| - **Public channels** are advisory. Non-matching members are *never* removed (anyone can still join a public channel by browsing or via a direct link). With auto-add enabled the policy still pulls matching users in; with auto-add disabled the channel surfaces under **Browse Channels > Recommended channels** for users whose attributes match. | ||
|
|
||
| Each ABAC channel access policy has an explicit active state that determines whether the policy will automatically add users who meet the policy's criteria but are not yet channel members. For private channels, the policy's rules are always enforced to remove members who no longer meet the required attribute rules, regardless of the active state. For public channels, no member is ever removed by ABAC — the rules are advisory only. | ||
|
|
||
| With channel access rules, Channel and Team Admins can: | ||
|
|
||
| - Create channel-specific access rules using a simple interface. | ||
| - Rules are **additive** to any system policies (both must be satisfied). | ||
| - Use rules that are **additive** to any system policies. For private channels, both must be satisfied for adds and invites. For public channels, the combined rules affect auto-add and recommendations only, and don't block joins or remove members. | ||
| - Automatic member synchronization with immediate feedback. | ||
| - Self-exclusion prevention to avoid locking yourself out. | ||
| - Self-exclusion prevention to avoid locking yourself out (private channels only). | ||
|
|
||
| Prerequisites | ||
| ------------- | ||
|
|
||
| - :doc:`Attribute-Based Access Control (ABAC) </administration-guide/manage/admin/attribute-based-access-control>` must be enabled by a System Admin in **System Console > System Attributes > Attribute-Based Access**. | ||
| - You need Channel Admin permissions and the ``manage_channel_access_rules`` permission. | ||
| - Self-service access rules in the **Access Control** tab of Channel Settings apply only to private channels. Membership policies apply to both public and private channels, with behavior that varies by channel type. See :ref:`Public and private channel behavior <administration-guide/manage/admin/abac-channel-access-rules:public and private channel behavior>`. | ||
| - Channel access rules are available for private and public channels, with behavior that varies by channel type. See :ref:`Public and private channel behavior <administration-guide/manage/admin/abac-channel-access-rules:public and private channel behavior>`. Default channels (such as Town Square and Off-Topic), shared channels, and group-synced channels remain ineligible. | ||
|
|
||
| Access Channel Settings | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| 1. In a private channel where you have Channel Admin permissions, select the channel name at the top of the center pane. | ||
| 1. In a private or public channel where you have Channel Admin permissions, select the channel name at the top of the center pane. | ||
| 2. Select **Channel Settings** from the dropdown menu. | ||
| 3. Navigate to the **Access Control** tab. This tab is only visible for private channels when you have the appropriate permissions and ABAC is enabled system-wide. | ||
| 3. Navigate to the **Membership Policy** tab. This tab is only visible for eligible channels when you have the appropriate permissions and ABAC is enabled system-wide. The tab is hidden on default channels, shared channels, and group-synced channels. | ||
|
|
||
| .. tip:: | ||
|
|
||
|
|
@@ -38,7 +43,7 @@ Configure access rules | |
|
|
||
| Channel access rules use the same simple interface as system policies, allowing you to create attribute-based conditions without complex syntax. | ||
|
|
||
| 1. In the **Access Control** tab, you'll see any inherited system policies at the top in a blue information banner (if applicable). | ||
| 1. In the **Membership Policy** tab, you'll see any inherited system policies at the top in a blue information banner (if applicable). | ||
| 2. Use the **Add attribute** button to create new access conditions: | ||
|
|
||
| - **Select attribute**: Choose from available user attributes | ||
|
|
@@ -58,33 +63,42 @@ Channel access rules use the same simple interface as system policies, allowing | |
| Auto-sync membership | ||
| ~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| The **Auto-add members based on access rules** toggle controls automatic membership management. This setting ensures that channel membership stays consistently aligned with the defined attribute rules, similar to how LDAP group channels work: | ||
| The **Auto-add members based on access rules** toggle controls automatic membership management. The behavior differs by channel type: | ||
|
|
||
| - **Private channels (hard gate)**: Membership stays consistently aligned with the rules, similar to how LDAP group channels work. | ||
|
|
||
| - **Enabled**: Users matching the rules are automatically added. If users temporarily lose attributes and later regain them, they will be automatically re-added. | ||
| - **Disabled**: Rules act as a gate (preventing unauthorized joins) but don't automatically add qualifying users. | ||
|
|
||
| - **Enabled**: Users matching the rules are automatically added to the channel. If users temporarily lose attributes and later regain them, they will be automatically re-added | ||
| - **Disabled**: Rules act as a gate (preventing unauthorized joins) but don't automatically add qualifying users | ||
| - **Public channels (advisory)**: ABAC never removes members — anyone can still join a public channel. | ||
|
|
||
| - **Enabled**: Matching users are automatically added (a convenience, not a gate). | ||
| - **Disabled**: The channel appears under **Browse Channels > Recommended channels** for users whose attributes match, surfacing the channel without adding anyone. | ||
|
|
||
| .. important:: | ||
|
|
||
| - Auto-add/auto-sync is checked on a per-channel policy basis, not inherited from parent system-wide policies. | ||
| - If a system policy has auto-sync enabled, Channel and Team Admins cannot disable it at the channel level. | ||
| - If a system policy has auto-sync disabled, Channel and Team Admins can choose to enable it for their channel. | ||
| - When no rules are configured, this toggle is automatically disabled. | ||
| - Regardless of the auto-sync setting, users who no longer meet required attribute rules are always removed during synchronization. | ||
| - On **private** channels, users who no longer meet required attribute rules are always removed during synchronization regardless of the auto-sync setting. On **public** channels, no member is ever removed by ABAC. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not from this PR, but how should we handle
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Soon this is going to be something else 😉 |
||
|
|
||
| Validation and safety | ||
| ~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Before saving changes, Mattermost validates your rules to prevent common issues: | ||
|
|
||
| - **Required fields**: All attribute selections and values must be completed | ||
| - **Self-exclusion prevention**: You cannot create rules that would remove yourself from the channel | ||
| - **Conflict detection**: Rules that create impossible conditions are identified | ||
| - **Required fields**: All attribute selections and values must be completed. | ||
| - **Self-exclusion prevention**: For private channels, you cannot save rules that would remove yourself from the channel. The check is skipped for public channels because they are advisory under ABAC and can't lock anyone out. | ||
| - **Conflict detection**: Rules that create impossible conditions are identified. | ||
|
|
||
| When you save changes that affect membership, a confirmation dialog shows you: | ||
|
|
||
| - How many users will be added or removed | ||
| - Option to view the specific users affected | ||
| - Confirmation required before applying changes | ||
| - How many users will be added or removed. | ||
| - Option to view the specific users affected. | ||
| - Confirmation required before applying changes. | ||
|
|
||
| Once a policy is attached to a channel, the channel cannot be converted between public and private until the policy is removed. The two modes have different semantics (advisory vs. hard gate), so a silent conversion would change what an existing policy actually does to its members. | ||
|
|
||
| Public and private channel behavior | ||
| ----------------------------------- | ||
|
|
@@ -210,29 +224,39 @@ Visual indicators | |
|
|
||
| **Channel Members panel:** | ||
|
|
||
| - Information banner at the top explains that attribute-based access is enabled. | ||
| - Information banner at the top explains that attribute-based access is enabled. The message differs by channel type: private channels indicate that access is restricted by user attributes, while public channels indicate that member recommendations are based on user attributes. | ||
| - Displays required attribute values as tags (e.g., "Engineering", "Confidential"). | ||
| - Tooltip on hover shows the attribute name for each value. | ||
|
|
||
| **Add Members modal:** | ||
|
|
||
| - Similar information banner and attribute value display. | ||
| - Users who don't match the access criteria won't appear in search results. | ||
| - Only eligible users can be selected and added to the channel. | ||
| - On **private** channels, users who don't match the access criteria won't appear in search results — only eligible users can be added. | ||
| - On **public** channels, the full team list is shown and matching users are surfaced with a **Recommended** tag at the top of the list. Anyone can still be added because public-channel ABAC is advisory. | ||
|
|
||
| **Browse Channels:** | ||
|
|
||
| - A **Recommended channels** filter is available in the channel-type dropdown when ABAC is enabled. Selecting it lists the public channels whose policies the user matches — useful when auto-add is disabled and the channel is offered as a recommendation rather than auto-joined. | ||
|
|
||
| Functional restrictions | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| When ABAC is enabled for a channel: | ||
| When ABAC is enabled for a **private** channel: | ||
|
|
||
| - **Search limitations**: Users who don't match access criteria don't appear in member search results. | ||
| - **Invitation restrictions**: Only users meeting attribute requirements can be added to the channel. | ||
| - **Guest user exclusions**: Private channels with ABAC policies cannot have guest users invited. | ||
| - **Automatic removal**: Users who lose required attributes are automatically removed during the next synchronization. | ||
|
|
||
| When ABAC is enabled for a **public** channel: | ||
|
|
||
| - **Search results are unfiltered**: All eligible team members appear in the Add Members modal so admins can still invite anyone; matching users carry a **Recommended** tag. | ||
| - **Recommendations**: With auto-add disabled, the channel surfaces under **Browse Channels > Recommended channels** for matching users. | ||
| - **Auto-add (when enabled)**: Matching users are added automatically. **Members are never removed** by ABAC — users can always leave on their own, and joining freely is unaffected because the channel is public. | ||
|
|
||
| .. note:: | ||
|
|
||
| These restrictions apply across all Mattermost clients, including web, desktop, and mobile, to ensure consistent security enforcement. | ||
| These behaviors apply across all Mattermost clients, including web, desktop, and mobile, to ensure consistent enforcement. | ||
|
|
||
| Troubleshooting and FAQs | ||
| --------------------------- | ||
|
|
@@ -242,15 +266,15 @@ Common questions about attribute-based access control implementation and usage. | |
| Permission and access | ||
| ~~~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| Why can't I see the Access Control tab in Channel Settings? | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
| Why can't I see the Membership Policy tab in Channel Settings? | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| The **Access Control** tab is only visible when all of these conditions are met: | ||
| The **Membership Policy** tab is only visible when all of these conditions are met: | ||
|
|
||
| - You have Channel Admin role or higher for the channel | ||
| - The channel is a private channel (not public, group message, or direct message) | ||
| - ABAC is enabled system-wide by a System Admin in **System Console > System Attributes > Attribute-Based Access** | ||
| - Your user role includes the ``manage_channel_access_rules`` permission | ||
| - You have Channel Admin role or higher for the channel. | ||
| - The channel is a private or public channel (not a default channel like Town Square or Off-Topic, group message, direct message, shared, or group-synced channel). | ||
| - ABAC is enabled system-wide by a System Admin in **System Console > System Attributes > Attribute-Based Access**. | ||
| - Your user role includes the ``manage_channel_access_rules`` permission. | ||
|
|
||
| Can Channel and Team Admins override system policies? | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
@@ -260,7 +284,14 @@ No. Channel rules are always **additive** to system policies. Users must satisfy | |
| What happens if I create rules that would exclude myself? | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| Mattermost prevents this with self-exclusion validation. If your rules would remove you from the channel, you'll see an error message and cannot save the changes until you adjust the rules or reset them. | ||
| For **private** channels, Mattermost prevents this with self-exclusion validation. If your rules would remove you from the channel, you'll see an error message and cannot save the changes until you adjust the rules or reset them. | ||
|
|
||
| For **public** channels, the self-exclusion check is skipped — public-channel ABAC is advisory, the policy can't kick anyone out, and you can always re-join a public channel directly. This lets you author a policy intended for a different team (for example, a Sales admin configuring an Engineering recommendation) without being blocked. | ||
|
|
||
| Can I convert a public channel to private (or vice versa) while a policy is attached? | ||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| No. The two modes have different semantics — a public-channel policy is advisory while a private-channel policy is a hard gate that removes non-matching members. A silent conversion would change what the existing policy does to its members, so Mattermost requires you to remove the policy first, convert the channel, and re-attach the policy if you still want it. | ||
|
|
||
| Rule configuration | ||
| ~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not new to this PR, but here we are referring to the
active stateand perhaps can be confusing, since we refer through the UI as "auto-add".There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, makes sense.