Docs: Update ABAC Channel Access Rules documentation for v11.3 #8671
Conversation
- Clarify that each ABAC channel access policy has explicit active state - Document independent behavior of channel-level (child) policies - Clarify auto-sync behavior follows channel policy's active state - Add troubleshooting note for verifying channel access control policy is active Co-authored-by: Combs7th <Combs7th@users.noreply.github.com>
|
Newest code from mattermost has been published to preview environment for Git SHA 931394f |
|
@isacikgoz - Do the above doc updates look accurate to you? |
cwarnermm
added
1: Dev Review
|
Newest code from mattermost has been published to preview environment for Git SHA 99875b3 |
isacikgoz
left a comment
isacikgoz
left a comment
There was a problem hiding this comment.
Thanks @Combs7th I think we might want to clarify the active state.
active state that determines whether the policy's rules are enforced and whether automatic member synchronization applies to the channel.
Regardless of active state, policy's rules will be enforced to remove members if they don't conform to required attribute rules.
|
|
||
| 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>`. | ||
|
|
||
| Each ABAC channel access policy has an explicit **active state** that determines whether the policy's rules are enforced and whether automatic member synchronization applies to the channel. Channel-level (child) ABAC policies behave independently and consistently, even when parent system-wide policies exist. |
There was a problem hiding this comment.
Regardless of the active state, if there is a policy applied to a channel it will be enforced. The active state indicates that the users matching to the policy will be automatically added. System-wide policies can be inherited, but they don't have an influence on whether auto-add feature also inherited or not. Only the rules are inherited, for auto-add we check the individual channel policy.
| ~~~~~~~~~~~~~~~~~~~~ | ||
|
|
||
| The **Auto-add members based on access rules** toggle controls automatic membership management: | ||
| The **Auto-add members based on access rules** toggle controls automatic membership management. Auto-sync behavior follows the channel policy's active state, reducing unexpected inheritance-related behavior: |
There was a problem hiding this comment.
It's not about inheritance but more giving the channel admin or system admin to decide if occasionally dropped members (eg. if users are losing attributes for some time), it will re-add them. Or you want to dedicate a channel to certain attribute and you always want to make sure people are in the channel. More like an alternative for LDAP group channels.
|
|
||
| .. important:: | ||
|
|
||
| - Auto-sync behavior is determined by the channel policy's active state, not inherited from parent policies. |
| Policy inheritance | ||
| -------------------- | ||
|
|
||
| Channel-level (child) ABAC policies now behave independently and consistently, even when parent system-wide policies exist. Each policy maintains its own active state and configuration. |
Updates the Mattermost Administration Guide section for ABAC Channel Access Rules to clarify:
Fixes #8666
Generated with Claude Code