Added docs for data spillage report generation#8934
Open
harshilsharma63 wants to merge 1 commit intomasterfrom
Open
Added docs for data spillage report generation#8934harshilsharma63 wants to merge 1 commit intomasterfrom
harshilsharma63 wants to merge 1 commit intomasterfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adds administrator documentation for the new quarantined-message report workflow in the Data Spillage Handling docs, extending the existing moderation guide with report-generation behavior and archive contents.
Changes:
- Documented a new Generate a report action in the quarantined message review flow.
- Added a new section describing when reviewers can download reports and how the remove/keep dialogs handle report generation.
- Added a report format section describing the ZIP/YAML archive layout and attachment handling.
|
|
||
| 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**. |
Comment on lines
+133
to
+140
| └── 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. |
Contributor
|
Newest code from mattermost has been published to preview environment for Git SHA 140ef27 |
Contributor
📝 WalkthroughWalkthroughDocumentation was added to the content flagging administration guide describing how to generate quarantined message reports, including access points from message details and action flows, default behaviours, and the ZIP archive structure with metadata and attachment contents. ChangesQuarantined Message Reporting Documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@source/administration-guide/manage/admin/content-flagging.rst`:
- Around line 111-112: Replace the low-severity tip admonition with a warning
admonition to reflect permanent data loss: change the existing ".. tip::" block
to ".. warning::" (the admonition that contains the sentence about generating a
report before removing a message) and preserve the text content; ensure
spacing/indentation matches RST admonition syntax so the warning renders
correctly in the admin content-flagging documentation.
- Around line 97-109: The docs for report generation lack guidance on secure
handling of downloaded quarantined-message ZIPs; add a new subsection after the
paragraph mentioning the Data Spillage Bot that explains secure report handling:
state that reports download to the reviewer's local device, recommend storage
and encryption aligned with organizational data-classification policies, specify
retention and secure disposal procedures, and describe access-control and
least-privilege recommendations for production vs development/test environments;
reference the “Download report” flow and “Data Spillage Bot” notification so
reviewers see the guidance in context.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 87f01ad9-d9d9-4783-883e-a075a0d957d4
📒 Files selected for processing (1)
source/administration-guide/manage/admin/content-flagging.rst
Comment on lines
+97
to
+109
| 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. |
Contributor
There was a problem hiding this comment.
Add secure report handling guidance.
The documentation explains how to generate reports but does not address secure handling of the downloaded ZIP archive, which contains "potentially spilled data" (line 109) including sensitive content, attachments, author emails (line 138), and PII. For production deployments, reviewers need guidance on:
- Where reports are downloaded (local device)
- Secure storage requirements aligned with organizational data classification policies
- Report retention and disposal procedures
- Access control for report files
Per coding guidelines on security-sensitive documentation, distinguish between development/test and production environments, and apply least privilege principles to data handling.
🛡️ Suggested addition after line 109
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.
+
+.. important::
+
+ Reports are downloaded to your local device and may contain sensitive data, including message content, file attachments, and author information. Handle downloaded reports according to your organization's data classification and retention policies. Store reports securely with appropriate access controls, and dispose of them properly when no longer needed for compliance or incident response purposes.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/administration-guide/manage/admin/content-flagging.rst` around lines
97 - 109, The docs for report generation lack guidance on secure handling of
downloaded quarantined-message ZIPs; add a new subsection after the paragraph
mentioning the Data Spillage Bot that explains secure report handling: state
that reports download to the reviewer's local device, recommend storage and
encryption aligned with organizational data-classification policies, specify
retention and secure disposal procedures, and describe access-control and
least-privilege recommendations for production vs development/test environments;
reference the “Download report” flow and “Data Spillage Bot” notification so
reviewers see the guidance in context.
Comment on lines
+111
to
+112
| .. 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. |
Contributor
There was a problem hiding this comment.
Use warning admonition for data loss.
The current tip admonition understates the severity. The content warns about permanent, unrecoverable data loss, which meets the guideline definition for warning: "meaningful risk such as broken behavior, data loss, security exposure, or likely user/admin mistakes with negative consequences."
⚠️ Correct admonition level
-.. tip::
+.. warning::
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.As per coding guidelines: "Use warning admonition for meaningful risk such as broken behavior, data loss, security exposure, or likely user/admin mistakes with negative consequences."
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| .. 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. | |
| .. warning:: | |
| 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. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@source/administration-guide/manage/admin/content-flagging.rst` around lines
111 - 112, Replace the low-severity tip admonition with a warning admonition to
reflect permanent data loss: change the existing ".. tip::" block to "..
warning::" (the admonition that contains the sentence about generating a report
before removing a message) and preserve the text content; ensure
spacing/indentation matches RST admonition syntax so the warning renders
correctly in the admin content-flagging documentation.
harshilsharma63
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Added docs for data spillage report generation feature
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-68522