V11.8 Docs

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

@@ -253,7 +253,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 +282,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 +291,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.                                                               |                                                                         |
 +---------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------+
 

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.

source/conf.py

@@ -526,9 +526,9 @@ def setup(app: Sphinx):
 # built documents.
 #
 # The short X.Y version.
-# version = '11.7'
+# version = '11.8'
 # The full version, including alpha/beta/rc tags.
-# release = '11.7'
+# release = '11.8'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

source/deployment-guide/mobile/mobile-troubleshooting.rst

@@ -20,6 +20,24 @@ Login with ADFS/Office365 is not working
 
 In line with Microsoft guidance we recommend `configuring intranet forms-based authentication for devices that do not support WIA <https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-intranet-forms-based-authentication-for-devices-that-do-not-support-wia>`_. 
 
+How do I attach mobile app logs to a message?
+---------------------------------------------
+
+Use ``/mobile-logs`` during mobile troubleshooting to let users attach Mattermost mobile app logs to messages. Running ``/mobile-logs on`` shows the **Attach app logs** option in the attachment menu of the message composer, so users can include device-side logs when messaging an administrator or support engineer. Users can also turn this option on or off from the **Report a problem** screen in the mobile app. The command responds with an ephemeral message visible only to the user who ran it.
+
+.. important::
+
+    This command requires Mattermost mobile app v2.38 or later.
+
+- Enable **Attach app logs** for yourself using ``/mobile-logs on``.
+- Disable **Attach app logs** for yourself using ``/mobile-logs off``.
+- Check whether **Attach app logs** is enabled using ``/mobile-logs status``.
+- System admins can manage the setting for another user by appending a username, such as ``/mobile-logs on @username``, ``/mobile-logs off @username``, or ``/mobile-logs status @username``.
+
+.. important::
+
+    Non-admin users can only manage their own preference. Attempts to target another account return a neutral **Unable to change mobile log settings for that user** message to avoid username enumeration. Preference changes made through this command are recorded in the audit log.
+
 I see a “Connecting…” bar that does not go away
 -----------------------------------------------
 
@@ -147,4 +165,4 @@ If you did not receive a push notification when testing push notifications, use
 
   To conserve disk space, once your push notification issue is resolved, go to  **System Console > Environment > Logging > File Log Level**, then select **ERROR** to switch your logging detail level from **DEBUG** to **Errors Only**.
 
-If push notifications are not being delivered on the mobile device, confirm that you're logged in to the **Native** mobile app session through **Profile > Security > View and Log Out of Active Sessions**. Otherwise, the `DeviceId` won't get registered in the `Sessions` table and notifications won't be delivered.
+If push notifications are not being delivered on the mobile device, confirm that you're logged in to the **Native** mobile app session through **Profile > Security > View and Log Out of Active Sessions**. Otherwise, the ``DeviceId`` won't get registered in the ``Sessions`` table and notifications won't be delivered.

source/integrations-guide/built-in-slash-commands.rst

@@ -63,4 +63,4 @@ More useful slash commands
 - Open the in-product Marketplace using ``/marketplace``.
 - Display a list of keyboard shortcuts using ``/shortcuts``.
 - Open the **Settings** screen using ``/settings``.
-- Log out of Mattermost using ``/logout``.
+- Log out of Mattermost using ``/logout``.