V11.8 Docs

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

@@ -821,9 +821,6 @@ ID attribute
 .. note::
   If a user's ID Attribute changes, a new Mattermost account is created that is not associated with the previous account. If you need to change this field after users have signed-in, use the :ref:`mmctl ldap idmigrate <administration-guide/manage/mmctl-command-line-tool:mmctl ldap idmigrate>` command.
 
-.. note::
-  The ID attribute value is matched verbatim - Mattermost applies no case normalization. With PostgreSQL's default case-sensitive collation, a change in casing is treated as a new user and a separate account is created. Ensure your AD/LDAP server returns this attribute with consistent casing.
-
 .. config:setting:: login-id-attribute
   :displayname: Login ID attribute (AD/LDAP > Account Synchronization)
   :systemconsole: Authentication > AD/LDAP
@@ -1032,9 +1029,6 @@ Group ID attribute
 .. note::
   This attribute is only used when AD/LDAP Group Sync is enabled and it is **required**.  See the :doc:`AD/LDAP Group Sync documentation </administration-guide/onboard/ad-ldap-groups-synchronization>` for more information.
 
-.. note::
-  The Group ID attribute value is matched verbatim - Mattermost applies no case normalization. With PostgreSQL's default case-sensitive collation, a change in casing means Mattermost no longer recognizes the previously synced group and treats it as a new, unlinked group. Ensure your AD/LDAP server returns this attribute with consistent casing.
-
 Synchronization performance
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -1561,9 +1555,6 @@ Id attribute
 | String input.                                                                                                        | - Environment variable: ``MM_SAMLSETTINGS_IDATTRIBUTE``      |
 +----------------------------------------------------------------------------------------------------------------------+--------------------------------------------------------------+
 
-.. note::
-  The ID attribute value is matched verbatim - Mattermost applies no case normalization. With PostgreSQL's default case-sensitive collation, a change in casing is treated as a new user and a separate account is created. Ensure your identity provider returns this attribute with consistent casing.
-
 .. config:setting:: guest-attribute
   :displayname: Guest attribute (SAML)
   :systemconsole: Authentication > SAML 2.0

source/administration-guide/configure/enabling-chinese-japanese-korean-search.rst

@@ -9,8 +9,7 @@ Chinese, Japanese and Korean search
 
 .. attention::
 
-   Starting in Mattermost v11.9, CJK post search is enabled by default on PostgreSQL.
-   In Mattermost v11.5 through v11.8, enable the `feature flag <https://developers.mattermost.com/contribute/more-info/server/feature-flags/#changing-feature-flag-values>`_ ``MM_FEATUREFLAGS_CJKSEARCH``.
+   Starting on Mattermost v11.5, searching for Chinese, Japanese or Korean (CJK) characters can be enabled with the `feature flag <https://developers.mattermost.com/contribute/more-info/server/feature-flags/#changing-feature-flag-values>`_ ``MM_FEATUREFLAGS_CJKSEARCH``.
 
    The general recommendation of `using either Elasticsearch or Opensearch once the server reaches 2.5 million posts <https://docs.mattermost.com/administration-guide/scale/enterprise-search.html#do-i-need-to-use-elasticsearch-or-aws-opensearch>`_ still applies.
 

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

@@ -18,6 +18,7 @@ Review and manage the following site configuration options in the System Console
 - `Public Links <#public-links>`__
 - `Notices <#notices>`__
 - `Connected Workspaces <#connected-workspaces>`__
+- `Classification Markings <#classification-markings>`__
 
 .. tip::
 
@@ -253,7 +254,7 @@ Report a Problem
 
 With self-hosted deployments, you can specify how the **Report a Problem** option behaves in the Mattermost app via the **Help** menu:
 
-- **Default link**: Uses the default Mattermost URL to report a problem. Customers with a Mattermost subscription are directed to the `Mattermost Support Portal <https://support.mattermost.com/hc/en-us/requests/new>`_. Community deployments are directed to `create a new issue on the Mattermost GitHub repository <https://github.com/mattermost/mattermost/issues/new>`_.
+- **Default**: Customers with a Mattermost license can open a support case by email with the Mattermost support team. Unlicensed Mattermost deployments are directed to the `troubleshooting forums <https://mattermost.com/pl/report_a_problem_unlicensed>`_.
 - **Email address**: Enables you to :ref:`enter an email address <administration-guide/configure/site-configuration-settings:report a problem email address>` that users will be prompted to send a message to when they choose **Report a Problem** in Mattermost.
 - **Custom link**: Enables you to :ref:`enter a URL <administration-guide/configure/site-configuration-settings:report a problem link>` that users will be directed to when they choose **Report a Problem** in Mattermost.
 - **Hide link**: Removes the **Report a Problem** option from Mattermost.
@@ -282,7 +283,7 @@ Report a Problem link
   :displayname: Report a Problem email (Customization)
   :systemconsole: Site Configuration > Customization
   :configjson: .SupportSettings.ReportAProblemMail
-  :environment: MM_SUPPORTSETTINGS_REPORTAPROBLMEMAIL
+  :environment: MM_SUPPORTSETTINGS_REPORTAPROBLEMMAIL
   :description: Enter the email address that users will be prompted to send a message to when they choose Report a Problem in Mattermost.
 
 Report a Problem email address
@@ -291,7 +292,7 @@ Report a Problem email address
 +---------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------+
 | This field sets the email address for the **Report a Problem** link in the channel                | - System Config path: **Site Configuration > Customization**            |
 | header **Help** menu.                                                                             | - ``config.json`` setting: ``SupportSettings`` > ``ReportAProblemMail`` |
-|                                                                                                   | - Environment variable: ``MM_SUPPORTSETTINGS_REPORTAPROBLMEMAIL``       |
+|                                                                                                   | - Environment variable: ``MM_SUPPORTSETTINGS_REPORTAPROBLEMMAIL``       |
 | String input. Cannot be left blank.                                                               |                                                                         |
 +---------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------+
 
@@ -2589,6 +2590,34 @@ Member sync batch size
 
 ----
 
+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.
+
+.. note::
+
+  Classification markings are informational only and aren't tied to access control decisions at this time.
+
+Configure classification markings:
+
+1. Go to **System Console > Site Configuration > Classification Markings**.
+2. Enable **Enable classification markings**.
+3. Select a **Classification preset**, or create custom classification levels.
+4. Configure classification level names, colors, and rank order.
+5. Optionally enable the **Global Classification Banner** under **Global Classification Indicators**.
+6. Select the **Banner visibility**:
+
+   - **Top only**
+   - **Top and bottom**
+
+7. Select the **Global classification level** to display.
+8. Select **Save**.
+
+----
+
 config.json-only settings
 -------------------------
 

source/administration-guide/manage/admin/content-flagging.rst

@@ -87,24 +87,108 @@ 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 :ref:`administration-guide/manage/admin/content-flagging: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.
+
+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:
+
+.. code-block:: 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:
+
+- **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 :ref:`administration-guide/manage/admin/content-flagging: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::
 
-- 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.
+   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.
 
 Best practice recommendations
 -----------------------------
 
-Before rolling out Data Spillage Handling organization-wide, we recommend communicating that the feature protects both users and the organization from accidental data spillage. Start with a pilot team to validate reviewer notifications and workflows, integrate the process with existing data-handling or incident-response playbooks, and require reporter and reviewer comments to ensure every decision is transparent and auditable.
+Before rolling out Data Spillage Handling organization-wide, we recommend communicating that the feature protects both users and the organization from accidental data spillage. Start with a pilot team to validate reviewer notifications and workflows, integrate the process with existing data-handling or incident-response playbooks, and require reporter and reviewer comments to ensure every decision is transparent and auditable.