V11.9 Docs

source/administration-guide/configure/integrations-configuration-settings.rst

@@ -176,6 +176,15 @@ In the System Console, enter URIs as a comma-separated list. When setting this v
 
 This setting applies only when :ref:`Enable dynamic client registration <administration-guide/configure/integrations-configuration-settings:enable dynamic client registration>` is enabled.
 
+Redirect URIs are matched per URL component. Patterns support two wildcards:
+
+- ``*`` matches any characters except ``/`` (for example, a single path segment or a hostname label).
+- ``**`` matches any characters including ``/`` (for example, a multi-segment path).
+
+Wildcards are applied within URL components only: host wildcards match against the host, path wildcards match against the path, and a wildcard in one component can't satisfy another component. For example, ``https://*.example.com/**`` matches ``https://app.example.com/callback`` but not ``https://attacker.example.net``.
+
+Query strings are matched only when the pattern explicitly includes one. A pattern without a query string (such as ``https://app.example.com/callback`` or ``https://app.example.com/**``) matches only redirect URIs that have no query string. To allow redirect URIs that carry query parameters, include a query component in the pattern, for example ``https://app.example.com/callback?tenant=*``. To allow a callback both with and without a query string, add both patterns.
+
 +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 | This feature's ``config.json`` setting is ``"DCRRedirectURIAllowlist": []`` with string array input, such as ``["https://example.com/callback", "https://app.example.com/oauth"]``.                 |
 +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

source/administration-guide/configure/plugins-configuration-settings.rst

@@ -1029,7 +1029,38 @@ Enable AV1 (Experimental)
 
 .. note::
 
-  Avoid enabling both this experimental configuration setting and the `Enable simulcast for screen sharing <#enable-simulcast-for-screen-sharing-experimental>`__ experimental configuration setting at the same time. 
+  Avoid enabling both this experimental configuration setting and the `Enable simulcast for screen sharing <#enable-simulcast-for-screen-sharing-experimental>`__ experimental configuration setting at the same time.
+
+.. config:setting:: enable-pluginsvideo
+  :displayname: Enable video calls in DMs (Experimental) (Plugins - Calls)
+  :systemconsole: Plugins > Calls
+  :configjson: PluginSettings.Plugins.com.mattermost.calls.enablevideo
+  :environment: MM_CALLS_ENABLE_VIDEO
+
+  - **true**: Enables experimental video calls in direct message (DM) channels.
+  - **false**: **(Default)** Video calls are disabled.
+
+Enable video calls in DMs (Experimental)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
++--------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------+
+| - **true**: Enables experimental video calls in direct message (DM)      | - System Config path: **Plugins > Calls**                                                                     |
+|   channels.                                                              | - ``config.json`` setting: ``PluginSettings`` > ``Plugins`` > ``com.mattermost.calls`` > ``enablevideo``      |
+| - **false**: **(Default)** Video calls are disabled.                     | - Environment variable: ``MM_CALLS_ENABLE_VIDEO``                                                             |
+|                                                                          |                                                                                                               |
+| Video is supported in DM calls on the desktop and web apps only. Mobile  |                                                                                                               |
+| users can't start video calls; when joining a DM call that includes      |                                                                                                               |
+| video, they receive voice and screen sharing only. Call recordings       |                                                                                                               |
+| capture voice and screen sharing only — video isn't recorded.            |                                                                                                               |
++--------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------+
+
+.. note::
+
+  The ability to enable video calls in DMs is currently :ref:`Experimental <administration-guide/manage/feature-labels:experimental>`.
+
+.. note::
+
+  If your deployment offloads calls to the :doc:`RTCD service </administration-guide/configure/calls-rtcd-setup>`, video in DM calls requires **rtcd v1.2.2 or later**. We recommend running the rtcd version that ships with your Calls plugin release (rtcd v1.2.5 for Calls v1.12.0) and keeping rtcd updated alongside the plugin. Deployments that use the plugin's built-in RTC server (no RTCD) support video without additional configuration.
 
 .. config:setting:: enable-pluginsdcsignaling
   :displayname: Use data channels for signaling media tracks (Plugins - Calls)

source/administration-guide/configure/site-configuration-settings.rst

@@ -2620,7 +2620,7 @@ Classification Markings
 
 From Mattermost v11.8, system admins can configure classification markings in the System Console by going to **Site Configuration > Classification Markings**.
 
-Classification markings define reusable classification levels that can be displayed as global or channel-level banners in the web and desktop apps. Each classification level includes a name, color, and rank order. You can select a preset, such as US DoD, NATO, UK GSCP, Canada, or Australia PSPF, or define custom classification levels.
+Classification markings define reusable classification levels that can be displayed as global or channel-level banners in the web and desktop apps. Each classification level includes a name, color, and rank order. You can select a preset, such as US DoD, NATO, UK GSCP, Canada, or Australia PSPF, or define custom classification levels. Levels are ordered using the same **Ranked** attribute type available for :doc:`user attributes </administration-guide/manage/admin/user-attributes>`, so each level sits at a defined position from lowest to highest.
 
 .. note::
 

source/administration-guide/manage/admin/abac-channel-access-rules.rst

@@ -83,6 +83,10 @@ The **Auto-add members based on access rules** toggle controls automatic members
   - When no rules are configured, this toggle is automatically disabled.
   - 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.
 
+.. note::
+
+  If a policy rule references attribute values from a ``shared_only`` or ``source_only`` attribute that you don't personally hold, those values appear as ``--------`` and the row is read-only. Test and Delete actions are also disabled for those rows. See :ref:`Attribute value masking <administration-guide/manage/admin/abac-system-wide-policies:attribute value masking>` for details.
+
 Validation and safety
 ~~~~~~~~~~~~~~~~~~~~~
 

source/administration-guide/manage/admin/abac-system-wide-policies.rst

@@ -44,7 +44,15 @@ You can add multiple rules to a single policy, and each rule can include multipl
          - **Ends with**: The attribute value must end with the specified value.
          - **Contains**: The attribute value must exist somewhere with the specified value.
 
-     3. Specify the attribute values that users must have to be granted access to the channel. 
+         When the selected attribute is a **Ranked** attribute (an ordered list of values, such as clearance or classification levels), the match options are ordered comparisons instead. These let you match everyone at or above a threshold rather than only an exact value:
+
+         - **Is exactly** / **Is not**: The value must exactly match, or must not match, the specified value.
+         - **Is at least**: The value must be equal to or higher than the specified value - for example, clearance *is at least* Secret matches Secret and every higher level.
+         - **Is greater than**: The value must be higher than the specified value.
+         - **Is at most**: The value must be equal to or lower than the specified value.
+         - **Is less than**: The value must be lower than the specified value.
+
+     3. Specify the attribute values that users must have to be granted access to the channel.
 
    .. tab:: Advanced Mode
 
@@ -141,4 +149,23 @@ Permission policies can be used to restrict the following actions based on user
 
 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 :ref:`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.
+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.
+
+Attribute value masking
+-----------------------
+
+From Mattermost v11.8, when a policy references attribute values that the editing admin doesn't personally hold, those values are hidden in the policy editor. This prevents admins from reading or copying sensitive attribute values they're not authorized to see, while still allowing the policy to enforce access control normally.
+
+Masking only applies to attributes configured with a ``shared_only`` or ``source_only`` access mode. Attributes with a ``public`` access mode are always visible to all admins. See :ref:`Attribute access modes <administration-guide/manage/admin/user-attributes:attribute access modes>` for details on how each mode controls value visibility.
+
+**What you'll see:**
+
+- Masked values appear as ``--------`` in the rule editor instead of the raw value.
+- Rows containing masked values are **read-only** and cannot be modified.
+- **Test rule** and **Delete** actions are disabled for rules that contain masked values.
+
+**Enforcement is unaffected:** masking applies to the editing UI only. The underlying rules continue to control channel access and permissions as configured.
+
+**To edit a masked rule**, ask the policy owner or another System Admin who holds the relevant attribute values to make the change.
+
+This behavior applies to both the table editor and the CEL editor, and also to Team Admin and Channel Admin policy editors in Team Settings and Channel Settings. Requires Enterprise Advanced license and the ``AttributeValueMasking`` feature flag.

source/administration-guide/manage/admin/user-attributes.rst

@@ -101,6 +101,7 @@ From Mattermost v11.8, user attributes include both a **Display Name** and a **N
       - **URL** for web site address-based profile attributes.
       - **Select** for a list of profile attribute values users can choose from. Specify each value followed by pressing **TAB** or **ENTER**. Values can be up to 64 characters long, and users can choose a single value.
       - **Multi-select** for a list of profile attribute values users can select from. Specify each value followed by pressing **TAB** or **ENTER**. Values can be up to 64 characters long, and users can choose multiple values.
+      - **Ranked** for an ordered list of values, where each value ranks higher or lower than the others - for example, clearance or classification levels such as *Public*, *Secret*, and *Top Secret*. Specify each value, then order the values from lowest to highest rank. Users can choose a single value. Because the values are ordered, :doc:`access control policies </administration-guide/manage/admin/abac-system-wide-policies>` can compare a ranked attribute against a threshold - for example, clearance *is at least* Secret - rather than only checking for an exact match.
 
 3. Specify the attribute's visibility as one of the following:
 
@@ -140,6 +141,19 @@ Manage attributes
 
 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.
 
+Attribute access modes
+-----------------------
+
+Each user attribute has an **access mode** that controls who can see its values when those values appear in access control policies. The access mode is set per attribute and determines whether an admin editing a policy can see the raw attribute values referenced in its rules.
+
+Access modes are not configurable through the System Console. They can only be set programmatically by a Mattermost plugin using the `Property Fields API <https://api.mattermost.com/#tag/properties>`_. Attributes created by system admins through the System Console always use the ``public`` access mode. A plugin that needs to restrict attribute visibility must create the field with ``protected: true`` and set the desired ``access_mode`` — this is typically done by plugins that sync sensitive attributes from an external identity source and need to control which admins can read those values.
+
+- **Public** (default): The attribute value is visible to all admins editing policies that reference it. No masking is applied.
+- **Shared only**: The attribute value is only visible to admins who personally hold that same value. Admins who don't hold the value see it masked (``--------``) in the policy editor.
+- **Source only**: The attribute value is only visible to the system source that set it (for example, the identity provider). All admins see it masked in the policy editor regardless of their own attribute values.
+
+Masking in the policy editor only applies to attributes with ``shared_only`` or ``source_only`` access mode. See :ref:`Attribute value masking <administration-guide/manage/admin/abac-system-wide-policies:attribute value masking>` for the editor behavior when masked values are present.
+
 Sync attributes with your identity provider
 --------------------------------------------
 

source/administration-guide/scale/performance-monitoring-metrics.rst

@@ -37,6 +37,7 @@ Cluster metrics
 - ``mattermost_cluster_cluster_health_score``: A score that gives an idea of how well it is meeting the soft-real time requirements of the gossip protocol.
 - ``mattermost_cluster_cluster_requests_total``: The total number of inter-node requests.
 - ``mattermost_cluster_cluster_event_type_totals``: The total number of cluster requests sent for any type.
+- ``mattermost_cluster_reliable_fallback_tcp``: The total length in bytes of the ``SendBestEffort`` calls (UDP) that had to fallback to ``SendReliable`` (TCP) because of the message length. This is a histogram with 8 buckets, from 32KiB to 4MiB. Ideally, the count of this metric should be always 0, but plugins may be misusing the websocket API and attempting to send large messages via UDP; in that case, plugins should be fixed to set `ReliableClusterSend <https://github.com/mattermost/mattermost/blob/4fe11a7d5d14616f3c31363762617ddfd99895df/server/public/model/websocket_message.go#L155-L157>`__ to true.
 
 Database metrics
 ~~~~~~~~~~~~~~~~