mirror of
https://github.com/mattermost/mattermost.git
synced 2026-09-19 10:12:47 +08:00
docs(P13d): reconcile Manage content drift — ABAC updates, telemetry, mmctl, health checks (#37482)
Ports content drift from the legacy Sphinx docs repo (mattermost/docs) since the P13 migration fork point into the corresponding Administration Guide > Manage MDX pages: - ABAC v11.7/v11.8: public channel membership policies (advisory vs. hard-gate behavior), channel-level permission policies, policy simulation, and team-scoped membership policies in Team Settings (abac-channel-access-rules, abac-system-wide-policies, attribute-based-access-control) - User Attributes: separate Display Name/Attribute name fields, backfill note, terminology updates - Content flagging: quarantined message report generation and post deletion report documentation - Autotranslation: translation target language and language-pair clarifications - Generating support packet: sanitize typo fixes, removed stale ElasticsearchSettings.ClientKey reference - Installing license key: Site Statistics -> System Statistics rename - Team/channel members: SetChannelMembers bulk API note - Telemetry: removed Rudder/Segment-specific reporting details following the telemetry stack migration - Statistics: Site Statistics -> System Statistics rename - Health check probes: corrected Go import path example - mmctl: documented --workers flag for import process, renamed Custom Profile Attribute -> User Attribute in cpa command docs - Logging: removed unused audit log file rotation settings from the Cloud defaults note Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Eva Sarafianou
@@ -3,28 +3,33 @@ title: "Channel-specific access rules"
|
||||
---
|
||||
<PlanAvailability slug="entry-adv" />
|
||||
|
||||
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 [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-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 [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 [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
|
||||
|
||||
- [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.
|
||||
- Channel access rules are available only for private channels.
|
||||
- Channel access rules are available for private and public channels, with behavior that varies by channel type. See [Public and private channel behavior](#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>
|
||||
|
||||
@@ -36,7 +41,7 @@ You can also assign ABAC rules to a channel directly from a channel's details pa
|
||||
|
||||
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
|
||||
- **Choose operator**: Select how the attribute should match:
|
||||
@@ -50,10 +55,14 @@ 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:
|
||||
|
||||
- **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
|
||||
- **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.
|
||||
- **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>
|
||||
|
||||
@@ -61,7 +70,7 @@ The **Auto-add members based on access rules** toggle controls automatic members
|
||||
- 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.
|
||||
|
||||
</Important>
|
||||
|
||||
@@ -69,15 +78,90 @@ The **Auto-add members based on access rules** toggle controls automatic members
|
||||
|
||||
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
|
||||
|
||||
Membership policies behave differently depending on the type of channel they're applied to:
|
||||
|
||||
- **Private channels**: Membership policies are enforced. Users who match the policy's rules are added, and users who don't match the rules are removed during synchronization.
|
||||
- **Public channels**: Membership policies are advisory. Matching users may be automatically added when auto-add is enabled, but non-matching members are not removed.
|
||||
- When auto-add is disabled for a public channel, matching channels are surfaced as **recommended** rather than enforcing membership.
|
||||
- Direct messages and group messages aren't eligible for membership policies.
|
||||
- Default channels such as **Town Square** and **Off-Topic** are excluded.
|
||||
|
||||
<Note>
|
||||
|
||||
Public channels with membership policies may appear in **Browse Channels** under **Recommended**, and matching users may be marked **Recommended** in the channel invite flow. See [Browse channels](/end-user-guide/collaborate/browse-channels) and [Manage channel members](/end-user-guide/collaborate/manage-channel-members) for the end-user experience.
|
||||
|
||||
</Note>
|
||||
|
||||
## Channel-level permission policies
|
||||
|
||||
From Mattermost v11.8.0, channel admins can define channel-level permission rules for file upload and file download based on user attributes and channel role. Applicable roles include **channel admin**, **channel member**, and **channel guest**.
|
||||
|
||||
For system-wide permission policies that restrict file upload and download actions, see [Permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies).
|
||||
|
||||
## Simulate access
|
||||
|
||||
From Mattermost v11.8.0, admins can use **Simulate access** in Channel Settings to preview whether selected users can perform actions such as uploading files or downloading files before saving policy changes.
|
||||
|
||||
- Simulation can evaluate draft rules before they're saved, so you can confirm the intended scope without affecting live channel access.
|
||||
- Some denied results may indicate that the decision came from another policy. In that case, Mattermost shows that access was denied by another policy without exposing policy details you aren't authorized to see.
|
||||
|
||||
<Note>
|
||||
|
||||
Channel-level permission policies and **Simulate access** are gated by the `PermissionPolicies` feature flag (`MM_FEATUREFLAGS_PERMISSIONPOLICIES`) and require a Mattermost Enterprise Advanced license. See the Mattermost developer documentation for details on [enabling feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development). Mattermost Cloud customers can request this feature flag be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004).
|
||||
|
||||
</Note>
|
||||
|
||||
## Manage team-scoped membership policies in Team Settings
|
||||
|
||||
From Mattermost v11.7, Team Admins can create, edit, and delete channel membership policies directly from Team Settings, scoped to channels within their team. This lets teams self-manage attribute-based membership for their own channels without requiring a System Admin to create or modify a system-wide policy.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- [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 Team Admin permissions for the team and the `manage_team_access_rules` permission.
|
||||
- Team-scoped membership policies can be assigned to both public and private channels within the team.
|
||||
|
||||
### Team Admin workflow
|
||||
|
||||
1. Open **Team Settings** from the team menu, and go to the **Membership Policies** tab. This tab is only visible to Team Admins with the `manage_team_access_rules` permission when ABAC is enabled system-wide.
|
||||
2. Select **Add Policy** and enter a name for the policy. Parent policy names must be unique; if you enter a name that's already in use, Mattermost displays a user-friendly error and prevents the policy from being saved.
|
||||
3. Define the attribute rules that determine which users can be members of channels assigned to this policy. Rules use the same attribute conditions available for channel-specific access rules.
|
||||
4. Assign the applicable private channels in the team to the policy.
|
||||
5. Select **Save** to create or update the policy. Team-scoped policies can be edited or deleted from the same tab at any time.
|
||||
|
||||
### Team Settings sync status footer
|
||||
|
||||
The **Membership Policies** tab includes a sync status footer that shows:
|
||||
|
||||
- **Last sync time**: The time of the most recent membership synchronization for policies in this team.
|
||||
- **Sync now**: An on-demand action that triggers an immediate synchronization for the team's policies.
|
||||
|
||||
Team-scoped sync is limited to the team admin's team scope. Triggering **Sync now** from Team Settings does not affect channels or policies outside the current team.
|
||||
|
||||
### Sync behavior by channel type
|
||||
|
||||
Sync behavior for team-scoped membership policies depends on the type of channel the policy is assigned to:
|
||||
|
||||
- **Public channels**: Sync is advisory and add-only. Users who match the policy's rules are added to the channel, but no users are removed if their attributes change.
|
||||
- **Private channels**: Sync is enforced. Users who match the policy's rules are added to the channel, and users who no longer match the rules are removed during the next synchronization.
|
||||
|
||||
### Automatic sync on policy changes
|
||||
|
||||
Mattermost automatically runs a sync job whenever a team-scoped membership policy is created, or its rules, assigned channels, or active state change. Team Admins don't need to manually trigger **Sync now** for these updates; the sync runs as part of the change.
|
||||
|
||||
## Policy inheritance
|
||||
|
||||
@@ -121,28 +205,38 @@ When channels have attribute-based access controls applied, users will see clear
|
||||
|
||||
**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.
|
||||
|
||||
</Note>
|
||||
|
||||
@@ -152,14 +246,14 @@ 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?
|
||||
|
||||
@@ -167,7 +261,13 @@ 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
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ You can add multiple rules to a single policy, and each rule can include multipl
|
||||
|
||||
1. In the System Console, go to **System Attributes \> Attribute-Based Access** and select **Add Policy**.
|
||||
|
||||
2. Enter a unique policy name.
|
||||
2. Enter a unique policy name. Parent access control policy names must be unique; if you enter a name that's already in use, Mattermost displays a user-friendly error message and prevents the policy from being saved until you choose a different name.
|
||||
|
||||
3. Choose whether to automatically add users who match your configured attribute values as new members. Automatic synchronization is disabled by default.
|
||||
|
||||
@@ -71,21 +71,46 @@ Advanced Mode is ideal for complex access control scenarios that require CEL syn
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Test rules
|
||||
### Simulate access
|
||||
|
||||
Select **Test access rule** to test the rule against your user base to return how many users would be granted access to the channel based on the current rule. Test your rules to ensure the intended scope and avoid unexpected access changes.
|
||||
|
||||
From Mattermost v11.8.0, you can use **Simulate access** to preview allowed and denied outcomes for specific users before saving policy changes:
|
||||
|
||||
1. Open the policy editor in the System Console.
|
||||
2. Select **Simulate access**.
|
||||
3. Choose the users you want to test.
|
||||
4. Review the allowed and denied outcomes by action, such as joining a channel or uploading and downloading files.
|
||||
5. Adjust the rules before saving.
|
||||
|
||||
Simulation can test draft policy changes before they affect live channel access or file permissions. Detailed rule and attribute information is shown only when the denial comes from the policy or scope you're editing; otherwise, Mattermost may show that access was denied by another policy.
|
||||
|
||||
<Note>
|
||||
|
||||
**Simulate access** and channel-level permission policies for file upload and file download are gated by the `PermissionPolicies` feature flag (`MM_FEATUREFLAGS_PERMISSIONPOLICIES`) and require a Mattermost Enterprise Advanced license. See the Mattermost developer documentation for details on [enabling feature flags in a self-hosted deployment](https://developers.mattermost.com/contribute/more-info/server/feature-flags/#self-hosted-and-local-development). Mattermost Cloud customers can request this feature flag be enabled by contacting their Mattermost Account Manager or by [creating a support ticket](https://support.mattermost.com/hc/en-us/requests/new?ticket_form_id=11184911962004).
|
||||
|
||||
</Note>
|
||||
|
||||
### Manage rules
|
||||
|
||||
You can apply changes to existing rules or remove rules at any time using either Simple Mode or Advanced Mode. Select **Save** to save your changes.
|
||||
|
||||
### Assign policies to private channels
|
||||
### Assign policies to channels
|
||||
|
||||
Specify the private channel that your access control policy applies to by selecting **Add channels** to search for and select the channels you want. You can assign the policy to multiple channels at once, or you can [assign it to individual channels](#define-access-controls-per-channel) later. Select **Save** to save your changes.
|
||||
From Mattermost v11.8, system-wide policies can be assigned to **both private and public channels**. Select **Add channels** to search for and select the channels you want. You can assign the policy to multiple channels at once, or you can [assign it to individual channels](#define-access-controls-per-channel) later. Select **Save** to save your changes.
|
||||
|
||||
The two channel types behave differently under the same policy:
|
||||
|
||||
- **Private channels** are hard-gated. The policy adds matching users (when auto-add is enabled), removes non-matching members during synchronization, and prevents non-matching users from being added or invited.
|
||||
- **Public channels** are advisory. The policy never removes members and never blocks anyone from joining. With auto-add enabled it automatically adds matching users; with auto-add disabled the channel appears under **Browse Channels \> Recommended channels** for matching users.
|
||||
|
||||
Before saving, you'll be prompted to confirm the impact of the change so you can review how it affects each channel type.
|
||||
|
||||
Default channels (such as Town Square and Off-Topic), shared channels, and group-synced channels remain ineligible — they are excluded from the channel selector.
|
||||
|
||||
<Note>
|
||||
|
||||
Private channels with attribute-based access control policies can't have guest users invited to them. Only users who match the defined attribute criteria can be added to ABAC-controlled channels, ensuring strict adherence to access control policies.
|
||||
Private channels with attribute-based access control policies can't have guest users invited to them. Only users who match the defined attribute criteria can be added to ABAC-controlled private channels, ensuring strict adherence to access control policies. Public channels remain joinable by anyone regardless of the policy.
|
||||
|
||||
</Note>
|
||||
|
||||
@@ -95,12 +120,14 @@ To delete a policy, select the **Delete** button next to the policy you want to
|
||||
|
||||
## Define access controls per channel
|
||||
|
||||
You can assign an existing access control policy to a private channels for more granular control over channel membership. This is useful when you need to apply different rules for different channels.
|
||||
You can assign an existing access control policy to a private or public channel for more granular control over channel membership. This is useful when you need to apply different rules for different channels.
|
||||
|
||||
1. In the System Console, go to **User Management \> Channels** to select the private channel you want to configure, and select **Edit**.
|
||||
1. In the System Console, go to **User Management \> Channels** to select the private or public channel you want to configure, and select **Edit**.
|
||||
2. In the **Channel Management** section, enable the **Enable attribute-based channel access** option.
|
||||
3. Under **Access policy**, select **Link to a policy** to select an existing policy.
|
||||
|
||||
Once a policy is attached, the channel's privacy can no longer be flipped between public and private until the policy is removed — see [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules#validation-and-safety).
|
||||
|
||||
<Tip>
|
||||
|
||||
You can also assign ABAC rules to a channel directly from a channel's details page in the System Console under **Channel Management** by enabling the **Enable attribute-based channel access** option. Under **Access policy**, select **Link to a policy** to select an existing policy.
|
||||
@@ -110,3 +137,16 @@ You can also assign ABAC rules to a channel directly from a channel's details pa
|
||||
### Remove channel policies
|
||||
|
||||
Disable the policy for the channel by selecting **Remove Policy**. You can then link the channel to a different policy if preferred.
|
||||
|
||||
## Permission policies
|
||||
|
||||
From Mattermost v11.7, System Admins can define attribute-based **permission policies** that restrict specific user actions in addition to channel membership. Permission policies use the same attribute-based rules as access policies, but they apply to user actions rather than channel access.
|
||||
|
||||
Permission policies can be used to restrict the following actions based on user attributes:
|
||||
|
||||
- **File upload**: Prevent users who don't match the defined attribute rules from uploading file attachments.
|
||||
- **File download**: Prevent users who don't match the defined attribute rules from downloading file attachments.
|
||||
|
||||
When a permission policy applies, users who don't match the configured attribute values can't perform the restricted action. Users may see file attachments as unavailable or redacted in messages they would otherwise have access to. See [Restricted file attachments](/end-user-guide/collaborate/share-files-in-messages#restricted-file-attachments) for the end-user-facing behavior.
|
||||
|
||||
Permission policies follow the same unique-name requirement as access policies: each parent permission policy must have a unique name, and Mattermost surfaces a user-friendly error if a duplicate name is entered.
|
||||
|
||||
@@ -7,10 +7,19 @@ From Mattermost v10.9, system admins in large or complex organizations who requi
|
||||
|
||||
Enforcing strict access controls based on user attributes eliminates manual role adjustment processes that can lead to security risks, inefficiencies, or inappropriate access, while maintaining security and compliance by ensuring that only authorized users can access specific Mattermost channels.
|
||||
|
||||
Attribute-based access control (ABAC) provides 2 levels of control:
|
||||
Attribute-based access control (ABAC) can be used with the following policy types:
|
||||
|
||||
- **System-wide policies** (managed by System Admins): Centralized policies that can be applied across multiple channels in the System Console. See [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies).
|
||||
- **Channel-specific rules** (managed by Channel Admins): Self-service access rules that Channel Admins can configure directly in Channel Settings for individual channels. See [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules).
|
||||
- **System-wide access policies** (managed by System Admins): Centralized policies created in the System Console that can be applied across multiple channels. See [System-wide attribute-based access policies](/administration-guide/manage/admin/abac-system-wide-policies).
|
||||
- **Permission policies** (managed by System Admins): Attribute-based restrictions on user actions such as file upload and file download. See [Permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies).
|
||||
- **Team-scoped membership policies** (managed by Team Admins): Channel membership policies that Team Admins can create, edit, and delete directly from Team Settings for channels in their team. See [Manage team-scoped membership policies in Team Settings](/administration-guide/manage/admin/abac-channel-access-rules#manage-team-scoped-membership-policies-in-team-settings).
|
||||
- **Channel-specific access rules** (managed by Channel Admins): Self-service access rules that Channel Admins can configure directly in Channel Settings for individual channels. See [Channel-specific access rules](/administration-guide/manage/admin/abac-channel-access-rules).
|
||||
|
||||
From Mattermost v11.8, ABAC policies can be applied to **both private and public channels**, with deliberately different semantics for each:
|
||||
|
||||
- **Private channels** are hard-gated by the policy. Non-matching members are removed during synchronization and only matching users can be added or invited.
|
||||
- **Public channels** are advisory. Anyone can still join freely, no member is ever removed by ABAC, and the policy is used either to **auto-add** matching users (when enabled) or to **recommend** the channel under **Browse Channels \> Recommended channels** (when auto-add is disabled).
|
||||
|
||||
Default channels (Town Square, Off-Topic), shared channels, and group-synced channels remain ineligible.
|
||||
|
||||
## Before you begin
|
||||
|
||||
@@ -26,10 +35,19 @@ From Mattermost v10.11, user-managed attributes are excluded from attribute-base
|
||||
|
||||
Once enabled, you have multiple ways to configure access policies in Mattermost:
|
||||
|
||||
From Mattermost v11.8.0, admins can configure membership policies for both public and private channels, permission policies for file upload and file download, and simulate policy outcomes before saving.
|
||||
|
||||
**System Admins can:**
|
||||
|
||||
- Create [system-wide access policies](/administration-guide/manage/admin/abac-system-wide-policies) that can be assigned across multiple channels in the System Console.
|
||||
- Create [system-wide access policies](/administration-guide/manage/admin/abac-system-wide-policies) that can be assigned across multiple channels in the System Console. Membership policies can be applied to both public and private channels, with [advisory behavior on public channels](/administration-guide/manage/admin/abac-channel-access-rules#public-and-private-channel-behavior).
|
||||
- Assign [individual channel policies](/administration-guide/manage/admin/abac-system-wide-policies#define-access-controls-per-channel) to specific channels in the System Console.
|
||||
- Define [permission policies](/administration-guide/manage/admin/abac-system-wide-policies#permission-policies) that restrict actions such as file upload and file download based on user attributes.
|
||||
- [Simulate policy outcomes](/administration-guide/manage/admin/abac-system-wide-policies#simulate-access) to preview whether selected users can perform actions such as joining a channel or uploading and downloading files before saving policy changes.
|
||||
|
||||
**Team Admins can:**
|
||||
|
||||
- Create, edit, and delete [team-scoped channel membership policies](/administration-guide/manage/admin/abac-channel-access-rules#manage-team-scoped-membership-policies-in-team-settings) for channels in their team directly from Team Settings, when granted the `manage_team_access_rules` permission.
|
||||
- Create and manage [team-level channel membership policies](/administration-guide/manage/admin/abac-team-channel-policies) in Team Settings, scoping attribute-based rules to one or more private channels within their team.
|
||||
|
||||
**Channel Admins can:**
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ title: "Set up Auto-translation (Beta)"
|
||||
|
||||
From Mattermost v11.5, auto-translation automatically translates channel messages into each user's preferred display language. This enables multilingual teams to collaborate without language barriers.
|
||||
|
||||
Auto-translation uses an asynchronous queue-based architecture. When a message is posted in a channel with auto-translation enabled, the message is queued for translation into every configured target language. Translated messages replace the original display for users whose display language matches a target language, and they can view the original text at any time by selecting the translation icon on the message.
|
||||
Auto-translation uses an asynchronous queue-based architecture. When a message is posted in a channel with auto-translation enabled, the message is queued for translation into every configured target language. Translated messages replace the original display for users whose display language matches a target language, and they can view the original text at any time by selecting the translation icon on the message. A user's translation target language is determined by their Mattermost display language (set via **Settings \> Display \> Language**); decoupling the translation target from the display language is not currently supported.
|
||||
|
||||
Two translation provider options are available:
|
||||
|
||||
@@ -61,9 +61,9 @@ To configure:
|
||||
|
||||
<Tip>
|
||||
|
||||
**Choosing between LibreTranslate and Agents**: LibreTranslate is a lightweight, self-hosted translation engine. The Agents provider uses an LLM backend and generally produces more accurate translations, especially for languages such as Japanese, Korean, and Chinese where contextual understanding improves quality. Consider your translation quality needs and existing infrastructure when choosing.
|
||||
**Choosing between LibreTranslate and Agents**: LibreTranslate is a lightweight, self-hosted translation engine. The Agents provider uses an LLM backend and generally produces more accurate translations, especially for languages such as Japanese, Korean, and Chinese where contextual understanding improves quality. Consider your translation quality needs and existing infrastructure when choosing. LibreTranslate does not support direct translation between all language pairs; for unsupported combinations it performs a pivot translation through an intermediate language (typically English), which can reduce accuracy for those pairs.
|
||||
|
||||
**Choosing an LLM for the Agents provider**: Smaller, faster models are recommended for auto-translation. Translation is a well-defined task that doesn't benefit from the extended reasoning capabilities of larger models — larger models may actually overthink the task, adding unnecessary latency without improving quality. A model like `gpt-3.5-turbo` provides accurate translations with lower latency.
|
||||
**Choosing an LLM for the Agents provider**: Smaller, faster models are recommended for auto-translation. Translation is a well-defined task that doesn't benefit from the extended reasoning capabilities of larger models — larger models may actually overthink the task, adding unnecessary latency without improving quality. Choose a small, low-latency model that is currently supported by your configured LLM provider and validated in your environment.
|
||||
|
||||
</Tip>
|
||||
|
||||
@@ -75,6 +75,12 @@ To configure:
|
||||
4. Configure [Languages allowed](/administration-guide/configure/site-configuration-settings#languages-allowed) — every message in auto-translation-enabled channels is translated into each language in this list.
|
||||
5. Select **Save**.
|
||||
|
||||
<Note>
|
||||
|
||||
The languages available in the **Languages allowed** list are controlled by the **Available languages** setting (`AvailableLocales`) under **Site Configuration \> Localization**. If that field is blank, all supported languages are available; otherwise only listed languages appear as selectable auto-translation targets. The `EnableExperimentalLocales` setting can make additional locale codes available. Note that some locales (such as `zh-Hans`) are in beta — portions of the Mattermost UI may still display in English, which is a UI localization limitation and does not affect message translation.
|
||||
|
||||
</Note>
|
||||
|
||||
Use the [Restrict autotranslation in direct and group messages](/administration-guide/configure/site-configuration-settings#restrict-autotranslation-in-direct-and-group-messages) setting to control whether auto-translation can be enabled in direct and group messages.
|
||||
|
||||
See the [auto-translation configuration reference](../../configure/site-configuration-settings#auto-translation) for all available settings.
|
||||
|
||||
@@ -27,20 +27,14 @@ Alternatively, you can configure Data Spillage Handling via the [config.json fil
|
||||
- **Same reviewers for all teams**: Set to **True** to apply one global reviewer list across all teams, or **False** to configure reviewers per team.
|
||||
- **Reviewers**: Start typing to search for users to assign as content reviewers.
|
||||
|
||||
<div class="important">
|
||||
|
||||
<div class="title">
|
||||
|
||||
Important
|
||||
|
||||
</div>
|
||||
<Important>
|
||||
|
||||
Choose reviewers carefully. Assigning reviewer roles grants access to potentially sensitive information and may expose data from private channels.
|
||||
|
||||
- A global reviewer can view quarantined messages from all teams and channels, including private channels they’re not a member of.
|
||||
- Team-specific reviewers can view quarantined messages from their assigned teams, including private channels within those teams they’re not members of.
|
||||
|
||||
</div>
|
||||
</Important>
|
||||
|
||||
- **Additional reviewers**: Optionally include:
|
||||
- **System Administrators**: System admins receive quarantined messages for all teams they are part of.
|
||||
@@ -92,21 +86,107 @@ Reviewers can select **View details** to take action as follows:
|
||||
- **Remove message**: Permanently delete the quarantined message from its original channel for all users. The status of the quarantined message changes to **Removed**.
|
||||
- **Keep message**: Dismiss the quarantine and restore the message if it was hidden. The status of the quarantined message changes to **Retained**.
|
||||
- **Add a comment**: Record the reason for the decision when required.
|
||||
- **Generate a report**: Download a report of the quarantined message and review activity for record-keeping or incident response. See [Generate a quarantined message report](#generate-a-quarantined-message-report) for details.
|
||||
|
||||
Once an action is taken, the **Status** field updates automatically. The **Data Spillage Bot** sends follow-up notifications to the reporter, author, and other reviewers based on how Data Spillage Handling is configured.
|
||||
|
||||
### Generate a quarantined message report
|
||||
|
||||
Reviewers can generate a downloadable report that captures the full context of a quarantined message and the associated review activity. Reports are useful for record-keeping, incident response, and preserving evidence before a message is permanently removed.
|
||||
|
||||
A report can be generated from any of the following entry points:
|
||||
|
||||
- **From the quarantined message details**: Select **Download report** from the message details panel. This option is available regardless of the quarantine's status, including **Pending**, **Reviewer Assigned**, **Removed**, or **Retained**.
|
||||
- **From the Remove message flow**: When you select **Remove message**, the confirmation dialog includes a **Download quarantined message report** checkbox, selected by default. With the checkbox selected, Mattermost generates and downloads the report before you can permanently remove the message. This safeguard ensures the record is preserved on your device before the message contents are deleted.
|
||||
- **From the Keep message flow**: When you select **Keep message**, the confirmation dialog includes the same checkbox. With the checkbox selected, Mattermost generates and downloads the report in the background while the keep action completes.
|
||||
|
||||
If you choose to skip the report download from the **Remove message** or **Keep message** flow, Mattermost asks you to confirm that you're proceeding without a report. The skip decision is recorded in the audit log.
|
||||
|
||||
If report generation fails (for example, due to a network interruption or session timeout), the dialog displays an error and offers a retry option. You can also skip the report and proceed with the action, or cancel and download the report later from the message details.
|
||||
|
||||
Each time a reviewer generates a report, the **Data Spillage Bot** notifies all content reviewers so an auditable record exists whenever a copy of the potentially spilled data is obtained.
|
||||
|
||||
<Tip>
|
||||
|
||||
We recommend generating a report before removing a message. Once a message is removed, its content, attachments, and edit history are permanently deleted and can't be recovered.
|
||||
|
||||
</Tip>
|
||||
|
||||
#### Report contents and format
|
||||
|
||||
Each report is a ZIP archive containing YAML metadata files and the original file attachments. YAML is used because it's both human-readable and machine-parseable, which makes the report suitable for manual review and for ingestion by downstream compliance or incident-response tooling.
|
||||
|
||||
The archive has the following structure:
|
||||
|
||||
``` text
|
||||
/
|
||||
├── report_metadata.yaml
|
||||
├── content_review.yaml
|
||||
├── post/
|
||||
│ ├── post.yaml
|
||||
│ └── attachments/
|
||||
│ └── <original attachment files>
|
||||
└── edit_history/
|
||||
└── <edit_post_id>/
|
||||
├── post.yaml
|
||||
└── attachments/
|
||||
└── <original attachment files>
|
||||
```
|
||||
|
||||
- **report_metadata.yaml**: Identifies the report itself, including the user ID and username of the reviewer who generated the report, the generation timestamp, and the report format version (used for forward compatibility if the report format changes in future releases).
|
||||
- **content_review.yaml**: Captures the data spillage event, including the reporter's user ID, username, selected reason, and comment; the report timestamp; whether the message was hidden during review; and, once the quarantine is resolved, the reviewer's user ID, username, comment, and action timestamp. For unresolved quarantines, reviewer fields are omitted.
|
||||
- **post/post.yaml**: Describes the quarantined message, including the post ID, author ID, author name, author email, message content, channel ID, channel display name, team ID, team display name, creation and update timestamps, pinned status, root ID, post properties, post metadata, reply count (for root posts), and the ordered list of edit history post IDs.
|
||||
- **post/attachments/**: The original files attached to the quarantined message, included verbatim.
|
||||
- **edit_history/\<edit_post_id\>/**: One subdirectory per previous version of the message, each containing a `post.yaml` and an `attachments/` directory in the same format as the base post directory.
|
||||
|
||||
To avoid duplication, attachment files are deduplicated across the entire archive by their file ID. Each unique attachment appears exactly once — under the base post if it exists in the current version of the message, or under the earliest edit-history entry that referenced it.
|
||||
|
||||
### Deleted messages
|
||||
|
||||
When a reviewer permanently removes a quarantined message, the message and all associated data are deleted from the database and can't be recovered, including:
|
||||
When a reviewer permanently removes a quarantined message, the message and all associated data are deleted from the database and file system and can't be recovered. The deletion covers:
|
||||
|
||||
- Message content and properties: The text of the message and any associated post properties.
|
||||
- File metadata: Information about files attached to the message (e.g., file names, IDs, and links to storage).
|
||||
- File metadata from edit history: Information about files attached to earlier versions of the message.
|
||||
- Edit history: All previous versions of the message and their timestamps.
|
||||
- Uploaded files: The actual files stored in Mattermost’s file storage (local, S3, etc.).
|
||||
- Priority data: Any message priority or importance settings.
|
||||
- Acknowledgements: Records of users who acknowledged the message.
|
||||
- Reminders: Any reminders created for the message.
|
||||
- **Post record**: The text of the message and any associated post properties. The content is scrubbed before the post is deleted.
|
||||
- **File attachments**: The files stored in Mattermost's file storage (local, S3, etc.).
|
||||
- **File attachment records**: The file info database rows for the message, including file names, IDs, and links to storage.
|
||||
- **Edit history**: Every prior revision of the message, along with file metadata from each revision.
|
||||
- **Priority metadata**: Any message priority or importance settings.
|
||||
- **Persistent notifications**: Any recurring notifications attached to the message.
|
||||
- **Acknowledgements**: Records of users who acknowledged the message.
|
||||
- **Reminders**: Any reminders created for the message.
|
||||
- **Thread, replies, and reactions**: The thread record, replies, and reaction data, if any, associated with the message.
|
||||
|
||||
#### Post deletion report
|
||||
|
||||
When a reviewer selects **Remove message**, the **Data Spillage Bot** posts a **Post Deletion Report** into the reviewer's content review thread for that quarantined message. The report is delivered to every reviewer who received the original quarantine notification, and is localized to each reviewer's language. Each post includes a short summary rendered inline, and a full report attached as a Markdown file named `deletion_report_<post_id>.md`.
|
||||
|
||||
The report records every cleanup step performed against the message and its associated data. The steps map directly to the data scope listed in [Deleted messages](#deleted-messages):
|
||||
|
||||
- **File attachments**: Files removed from file storage.
|
||||
- **File attachment records**: File info database rows for the message.
|
||||
- **Edit history**: Every prior revision of the message. Each revision is reported as its own sub-step so that reviewers can see exactly which revisions were cleared.
|
||||
- **Priority metadata**: Message priority and importance settings.
|
||||
- **Persistent notifications**: Recurring notifications attached to the message.
|
||||
- **Acknowledgements**: Records of users who acknowledged the message.
|
||||
- **Reminders**: Reminders set on the message.
|
||||
- **Thread, replies, and reactions**: The thread record, replies, and reaction data associated with the message.
|
||||
- **Post record**: The post itself. The content is scrubbed before the post is deleted.
|
||||
|
||||
Each step is assigned one of the following statuses:
|
||||
|
||||
- **Removed** ✅: The data was successfully deleted.
|
||||
- **Not applicable** ➖: There was no data of this type to delete.
|
||||
- **Partial** ⚠️: Some items of this type were deleted, but at least one failed. This status most often appears under **Edit history** when one revision can't be deleted.
|
||||
- **Failed** ❌: The step didn't complete. The report includes an error log so reviewers and System Administrators can inspect what went wrong.
|
||||
|
||||
When every step is **Removed** or **Not applicable**, no further action is required. The report serves as the auditable record of the deletion.
|
||||
|
||||
When any step reports **Partial** or **Failed**, the report displays an *incomplete* warning. Reviewers should escalate to a System Administrator, who can use the attached `deletion_report_<postId>.md` file - including the full per-step error log - to perform manual remediation and confirm that the data is fully removed.
|
||||
|
||||
<Note>
|
||||
|
||||
The post deletion report is the single source of truth for post-removal auditing. It isn't stored elsewhere in the System Console, so the reviewer thread containing the report should be retained in line with your organization's audit retention policy.
|
||||
|
||||
</Note>
|
||||
|
||||
## Best practice recommendations
|
||||
|
||||
|
||||
@@ -44,11 +44,11 @@ Downloaded Support Packet to mattermost_support_packet_.zip
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Santitize confidential data
|
||||
## Sanitize confidential data
|
||||
|
||||
Please sanitize any confidential data you wish to exclude before sharing the packet with Mattermost.
|
||||
|
||||
When present, the following information is automatically santized during packet generation: `LdapSettings.BindPassword`, `FileSettings.PublicLinkSalt`, `FileSettings.AmazonS3SecretAccessKey`, `EmailSettings.SMTPPassword`, `GitLabSettings.Secret`, `GoogleSettings.Secret`, `Office365Settings.Secret`, `OpenIdSettings.Secret`, `SqlSettings.DataSource`, `SqlSettings.AtRestEncryptKey`, `ElasticsearchSettings.Password`, `All SqlSettings.DataSourceReplicas`, `All SqlSettings.DataSourceSearchReplicas`, `MessageExportSettings.GlobalRelaySettings.SmtpPassword`, `ServiceSettings.SplitKey`, `FileSettings.ExportAmazonS3SecretAccessKey`, `ElasticsearchSettings.ClientKey`, `ServiceSettings.GoogleDeveloperKey`, and `ServiceSettings.GiphySdkKey` (from Mattermost v11.6.0).
|
||||
When present, the following information is automatically sanitized during packet generation: `LdapSettings.BindPassword`, `FileSettings.PublicLinkSalt`, `FileSettings.AmazonS3SecretAccessKey`, `EmailSettings.SMTPPassword`, `GitLabSettings.Secret`, `GoogleSettings.Secret`, `Office365Settings.Secret`, `OpenIdSettings.Secret`, `SqlSettings.DataSource`, `SqlSettings.AtRestEncryptKey`, `ElasticsearchSettings.Password`, `All SqlSettings.DataSourceReplicas`, `All SqlSettings.DataSourceSearchReplicas`, `MessageExportSettings.GlobalRelaySettings.SmtpPassword`, `ServiceSettings.SplitKey`, `FileSettings.ExportAmazonS3SecretAccessKey`, `ServiceSettings.GoogleDeveloperKey`, and `ServiceSettings.GiphySdkKey` (from Mattermost v11.6.0).
|
||||
|
||||
<Important>
|
||||
|
||||
@@ -65,7 +65,7 @@ Add the generated Support Packet to a [standard support request](https://support
|
||||
|
||||
<Important>
|
||||
|
||||
Disable debug logging once you've generated the Support Packet. Debug logging can cause log files to expand substantially, and may adversely impact server performance. We recommend enabling it temporarily, or in development environments, but not production enviornments.
|
||||
Disable debug logging once you've generated the Support Packet. Debug logging can cause log files to expand substantially, and may adversely impact server performance. We recommend enabling it temporarily, or in development environments, but not production environments.
|
||||
|
||||
</Important>
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ You don't need to wait for your current license key to expire before replacing i
|
||||
|
||||
<Tip>
|
||||
|
||||
To review license usage before uploading a new key, go to **System Console \> Reporting \> Site Statistics**. The **Total Activated Users** field shows the primary paid seat count used for license validation. Review **Single-channel Guests** separately because guests in exactly one channel are tracked outside the primary paid seat count, are free up to a 1:1 ratio with licensed seats, and generate warnings instead of hard enforcement when that allowance is exceeded.
|
||||
To review license usage before uploading a new key, go to **System Console \> Reporting \> System Statistics**. The **Total Activated Users** field shows the primary paid seat count used for license validation. Review **Single-channel Guests** separately because guests in exactly one channel are tracked outside the primary paid seat count, are free up to a 1:1 ratio with licensed seats, and generate warnings instead of hard enforcement when that allowance is exceeded.
|
||||
|
||||
</Tip>
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ System attributes enable you to customize user profile attributes to match your
|
||||
|
||||
From Mattermost v11, you have enhanced control over these user attributes through admin-managed vs user-editable settings. By default, attributes are admin-managed for security, but you can explicitly allow user editing for specific attributes that don't impact access control or sensitive organizational data. These user attributes supplement existing user details visible from the user's profile picture.
|
||||
|
||||
|
||||
|
||||
|
||||
## Before you begin
|
||||
|
||||
@@ -92,6 +92,8 @@ For security reasons, attributes used in ABAC policies are admin-managed by defa
|
||||
|
||||
You can define and manage up to 20 system attributes using the System Console. Each attribute becomes a user profile option users can populate, unless you disable the **Editable by Users** option, available from Mattermost v11. Once you reach the maximum of 20 attributes, you can't create new attributes until you [delete attributes](#manage-attributes) you no longer need.
|
||||
|
||||
From Mattermost v11.8, user attributes include both a **Display Name** and a **Name**. The Display Name is the label shown to users and admins in Mattermost. The Name is the internal attribute identifier used in API references and [attribute-based access control (ABAC)](/administration-guide/manage/admin/attribute-based-access-control) policy expressions. When you create a new user attribute, Mattermost can generate the Name from the Display Name, formatted as a CEL-safe identifier. Saved ABAC policies continue to reference the internal name using `user.attributes.<name>`.
|
||||
|
||||
<Note>
|
||||
|
||||
When you disable the **Editable by Users** option for an attribute, only admins can set its value using [mmctl cpa](/administration-guide/manage/mmctl-command-line-tool#mmctl-cpa) commands.
|
||||
@@ -102,7 +104,8 @@ When you disable the **Editable by Users** option for an attribute, only admins
|
||||
|
||||
2. Enter the following details:
|
||||
|
||||
> - **Attribute name**: Enter a unique name for the attribute. Attribute names can be up to 40 characters long.
|
||||
> - **Display Name**: Enter a display name for the attribute that will be shown in any user facing UI.
|
||||
> - **Attribute name**: Attribute name will be automatically generated from the provided Display Name. It can be overriden and with a preferred unique name for the attribute. Attribute names can be up to 40 characters long. The attribute name is used as the Common Expression Language (CEL) identifier in access control policies. It must start with a letter or underscore, and can contain only letters, numbers, and underscores. Reserved CEL words aren't allowed, including `true`, `false`, `null`, `in`, `as`, `break`, `const`, `continue`, `else`, `for`, `function`, `if`, `import`, `let`, `loop`, `package`, `namespace`, `return`, `var`, `void`, and `while`.
|
||||
> - **Type**: Specify the type of attribute as one of the following:
|
||||
> - **Text** for text-based profile attributes.
|
||||
> - **Phone** for phone number-based profile attributes.
|
||||
@@ -134,17 +137,24 @@ Duplicate existing attributes by selecting **More** <img src="/img/ui/dots-horiz
|
||||
## Manage attributes
|
||||
|
||||
- **Modify**: Select the attribute fields to make inline changes to the attribute's name, type, or values. Select **More** <img src="/img/ui/dots-horizontal_F01D8.svg" alt="Use the More icon to access additional message options." className="theme-icon" /> to change a attribute's visibility.
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11.8, existing user attributes are backfilled so the Display Name initially matches the Name. If the Display Name is empty or unavailable, Mattermost falls back to showing the Name. Duplicate display names are permitted, but internal names remain unique.
|
||||
|
||||
</Note>
|
||||
|
||||
- **Order**: Control the order you want attributes to appear in user profiles by dragging and dropping them in the list.
|
||||
- **Delete**: Delete attributes you no longer need or want by selecting **More** <img src="/img/ui/dots-horizontal_F01D8.svg" alt="Use the More icon to access additional message options." className="theme-icon" /> and selecting **Delete property**.
|
||||
|
||||
<Note>
|
||||
|
||||
When updating custom profile attributes via API or automation, the `attrs` object replaces existing attribute settings rather than merging. If you send only visibility, the sort order resets to `0` unless you include `sort_order` in the same request. If a patch fails, the API may return the error string "Unable to patch Custom Profile Attribute field".
|
||||
When updating user attributes via API or automation, the `attrs` object replaces existing attribute settings rather than merging. If you send only visibility, the sort order resets to `0` unless you include `sort_order` in the same request. If a patch fails, the API may return the error string "Unable to patch User Attribute field".
|
||||
|
||||
</Note>
|
||||
|
||||
- **User Edit Permissions**: From Mattermost v11, all user attributes are admin-managed by default for enhanced security. To allow user editing for specific attributes, administrators can enable this through the **More** <img src="/img/ui/dots-horizontal_F01D8.svg" alt="Use the More icon to access additional message options." className="theme-icon" /> menu and selecting **Allow user editing**. This should only be enabled for attributes that do not impact security access controls or organizational policies. Attributes used in ABAC policies should remain admin-managed unless there's a specific business need and the security implications are fully understood.
|
||||
- **Edit User Attribute Values**: From Mattermost v11.1, you can view and update custom profile attribute values for individual users through the System Console. See the [Manage user attributes](/administration-guide/configure/user-management-configuration-settings#manage-user-attributes) documentation for details.
|
||||
- **Edit User Attribute Values**: From Mattermost v11.1, you can view and update user attribute values for individual users through the System Console. See the [Manage user attributes](/administration-guide/configure/user-management-configuration-settings#manage-user-attributes) documentation for details.
|
||||
|
||||
In cases where multiple system admins manage system attributes, refresh your web browser instance to see real-time updates to system attributes made by other admins.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ A sample request is included below. The endpoint checks if the server is up and
|
||||
This endpoint can also be provided to schedulers like [Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
|
||||
|
||||
``` go
|
||||
import github.com/mattermost/mattermost/tree/master/server/public/model"
|
||||
import "github.com/mattermost/mattermost/server/public/model"
|
||||
|
||||
Client := model.NewAPIv4Client("https://your-mattermost-url.com")
|
||||
Client.Login("email@domain.com", "Password1")
|
||||
|
||||
@@ -267,14 +267,7 @@ From Mattermost v10.11, go to **System Console \> Compliance \> Audit Logging**
|
||||
|
||||
- From Mattermost v10.11, Cloud deployments include certificate-based audit logging capabilities not available within self-hosted deployments.
|
||||
|
||||
- Cloud-based deployments use the following self-hosted audit logging default values:
|
||||
|
||||
> - FileEnabled: false
|
||||
> - FileMaxSizeMB: 100
|
||||
> - FileMaxAgeDays: 0 (no limit)
|
||||
> - FileMaxBackups: 0 (retain all)
|
||||
> - FileCompress: false
|
||||
> - FileMaxQueueSize: 1000
|
||||
- Cloud-based deployments use the following self-hosted audit logging default values: `FileEnabled: false`
|
||||
|
||||
- Cloud deployments can't configure local file-based audit logging, and all file-related settings are hidden.
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ This feature was developed to a large extent by community contributions and we'd
|
||||
- [mmctl bot](#mmctl-bot) - Bot Management
|
||||
- [mmctl channel](#mmctl-channel) - Channel Management
|
||||
- [mmctl command](#mmctl-command) - Command Management
|
||||
- [mmctl cpa](#mmctl-cpa) - Custom Profile Attribute Management
|
||||
- [mmctl cpa](#mmctl-cpa) - User Attribute Management
|
||||
- [mmctl completion](#mmctl-completion) - Generate autocompletion scripts for bash, fish, powershell, and zsh
|
||||
- [mmctl compliance-export](#mmctl-compliance-export) - Compliance Export Management
|
||||
- [mmctl config](#mmctl-config) - Configuration Management
|
||||
@@ -1970,7 +1970,7 @@ mmctl completion zsh [flags]
|
||||
Manage User Attributes for extended user profile information.
|
||||
|
||||
> Child Commands
|
||||
> - [mmctl cpa field](#mmctl-cpa-field) - Manage CPA fields
|
||||
> - [mmctl cpa field](#mmctl-cpa-field) - Manage User Attribute fields
|
||||
|
||||
**Options**
|
||||
|
||||
@@ -1982,13 +1982,13 @@ Manage User Attributes for extended user profile information.
|
||||
|
||||
**Description**
|
||||
|
||||
Manage Custom Profile Attribute fields.
|
||||
Manage User Attribute fields.
|
||||
|
||||
> Child Commands
|
||||
> - [mmctl cpa field create](#mmctl-cpa-field-create) - Create a new CPA field
|
||||
> - [mmctl cpa field delete](#mmctl-cpa-field-delete) - Delete a CPA field
|
||||
> - [mmctl cpa field edit](#mmctl-cpa-field-edit) - Edit a CPA field
|
||||
> - [mmctl cpa field list](#mmctl-cpa-field-list) - List CPA fields
|
||||
> - [mmctl cpa field create](#mmctl-cpa-field-create) - Create a new User Attribute field
|
||||
> - [mmctl cpa field delete](#mmctl-cpa-field-delete) - Delete a User Attribute field
|
||||
> - [mmctl cpa field edit](#mmctl-cpa-field-edit) - Edit a User Attribute field
|
||||
> - [mmctl cpa field list](#mmctl-cpa-field-list) - List User Attribute fields
|
||||
|
||||
**Options**
|
||||
|
||||
@@ -2000,7 +2000,7 @@ Manage Custom Profile Attribute fields.
|
||||
|
||||
**Description**
|
||||
|
||||
Create a new Custom Profile Attribute field.
|
||||
Create a new User Attribute field.
|
||||
|
||||
**Format**
|
||||
|
||||
@@ -2042,7 +2042,7 @@ mmctl cpa field create "Location" --type select --options "New York,London,Tokyo
|
||||
|
||||
**Description**
|
||||
|
||||
Delete an existing Custom Profile Attribute field.
|
||||
Delete an existing User Attribute field.
|
||||
|
||||
**Format**
|
||||
|
||||
@@ -2082,7 +2082,7 @@ mmctl cpa field delete location-field-002 --force
|
||||
|
||||
**Description**
|
||||
|
||||
Edit an existing Custom Profile Attribute field.
|
||||
Edit an existing User Attribute field.
|
||||
|
||||
**Format**
|
||||
|
||||
@@ -2126,7 +2126,7 @@ mmctl cpa field edit location-field-002 --options "New York,London,Tokyo,Sydney"
|
||||
|
||||
**Description**
|
||||
|
||||
List all Custom Profile Attribute fields.
|
||||
List all User Attribute fields.
|
||||
|
||||
**Format**
|
||||
|
||||
@@ -4058,8 +4058,11 @@ mmctl import process 35uy6cwrqfnhdx3genrhqqznxc_import.zip
|
||||
-h, --help help for status
|
||||
--bypass-upload File is read directly from the filesystem, instead of being processed from the server. Supported in --local mode only.
|
||||
--extract-content Document attachments will be extracted and indexed during the import process. We recommend disabling this to improve performance.
|
||||
--workers int The number of concurrent import worker goroutines. Controls database load during import. When set to `0` (default), uses the number of CPUs available. Maximum allowed is 4x the CPU count.
|
||||
```
|
||||
|
||||
Use `--workers` to reduce concurrency, for example `--workers 1`, when running imports against a live server to minimize database load at the cost of longer import duration.
|
||||
|
||||
**Options inherited from parent commands**
|
||||
|
||||
``` sh
|
||||
|
||||
@@ -13,7 +13,7 @@ To maximize performance for large enterprise deployments, statistics for total m
|
||||
|
||||
For advanced metrics for Entry, Enterprise, and Enterprise deployments, [see performance monitoring documentation to learn more](/administration-guide/scale/deploy-prometheus-grafana-for-performance-monitoring).
|
||||
|
||||
## Site statistics
|
||||
## System statistics
|
||||
|
||||
System statistics are viewable under **System Console \> Reporting**. The data shown here is a cumulative sum across all teams on the system.
|
||||
|
||||
@@ -132,10 +132,10 @@ To enable team admins to access their team's statistics:
|
||||
|
||||
|
||||
|
||||
2. Under **Privileges**, expand the **Reporting** section, set **Team Statistics** to **Read only**, then set **Site Statistics** and **Server Logs** to **No access**.
|
||||
2. Under **Privileges**, expand the **Reporting** section, set **Team Statistics** to **Read only**, then set **System Statistics** and **Server Logs** to **No access**.
|
||||
3. Set all other privileges to **No access** to restrict all users with the **Viewer** role to access only the **Team Statistics** page in the System Console.
|
||||
|
||||
|
||||
|
||||
|
||||
4. Under **Assigned People**, select **Add People** to assign team admins to the **Viewer** role, and enable them to access their team's statistics.
|
||||
|
||||
|
||||
@@ -137,3 +137,9 @@ A list of all members in a channel is visible to system admins. Members can be a
|
||||
- Member
|
||||
- Channel admin
|
||||
- System admin
|
||||
|
||||
<Note>
|
||||
|
||||
From Mattermost v11.5.2, system admins can set the complete membership of a channel in a single API call. The server computes the diff against the current membership and adds or removes users as needed. See the [API documentation](https://api.mattermost.com/#tag/channels/operation/SetChannelMembers) for details.
|
||||
|
||||
</Note>
|
||||
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user