Added docs for deletion summary feature#8933
Conversation
📝 WalkthroughWalkthroughUpdated the content flagging administration guide documentation to expand the "Deleted messages" section with a comprehensive enumeration of deleted data categories (post properties, file attachments, edit history, metadata, notifications, acknowledgements, reminders, and thread/reply/reaction data). Added a new "Post deletion report" section describing the Data Spillage Bot's auditable per-reviewer cleanup report with status outcomes and remediation guidance, plus an audit retention note. ChangesContent Deletion and 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 unit tests (beta)
Review rate limit: 4/5 reviews remaining, refill in 12 minutes. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 132-138: The guidance under "When any step reports **Partial** or
**Failed**" and the note about the post deletion report being the single source
of truth should use stronger admonitions: replace the paragraph that begins
"When any step reports **Partial** or **Failed**..." with a .. warning:: block
that clearly signals escalation and use of the attached
deletion_report_<postId>.md for remediation, and change the existing ".. note::"
paragraph that starts "The post deletion report is the single source of
truth..." to an .. important:: admonition to emphasize audit-retention
requirements; ensure the text content remains the same but wrapped in the new
admonition directives.
🪄 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: 61d61f1f-428e-4fa2-83f7-a4d83ce0acfb
📒 Files selected for processing (1)
source/administration-guide/manage/admin/content-flagging.rst
| 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. |
There was a problem hiding this comment.
Use stronger admonitions for incomplete deletion risk and audit-retention constraints
This section currently under-signals high-impact guidance. Incomplete deletion outcomes should be a .. warning::, and the single-source-of-truth audit-retention statement should be .. important::.
Suggested minimal diff
-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.
+.. warning::
+
+ 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::
+.. important::
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.As per coding guidelines, "Use warning admonition for meaningful risk such as ... data loss, security exposure" and "Use important admonition for ... high-impact information that materially affects ... compliance."
🤖 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
132 - 138, The guidance under "When any step reports **Partial** or **Failed**"
and the note about the post deletion report being the single source of truth
should use stronger admonitions: replace the paragraph that begins "When any
step reports **Partial** or **Failed**..." with a .. warning:: block that
clearly signals escalation and use of the attached deletion_report_<postId>.md
for remediation, and change the existing ".. note::" paragraph that starts "The
post deletion report is the single source of truth..." to an .. important::
admonition to emphasize audit-retention requirements; ensure the text content
remains the same but wrapped in the new admonition directives.
There was a problem hiding this comment.
Pull request overview
Adds administrator documentation for the Data Spillage Handling “post deletion report” (deletion summary) that’s generated when reviewers remove quarantined messages, and expands the documented scope of what gets deleted.
Changes:
- Reworks the “Deleted messages” section to enumerate specific data and metadata removed during quarantine-based deletion.
- Adds a new “Post deletion report” section describing the report content, attached artifact, and step status meanings.
- Adds retention guidance for audit purposes.
| When a reviewer permanently removes a quarantined message, the message and all associated data are deleted from the database 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. |
| - **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 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_<postId>.md``. |
| 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_<postId>.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`: | ||
|
|
|
|
||
| .. 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. |
|
Newest code from mattermost has been published to preview environment for Git SHA 11b87d2 |
Summary
Added docs for data spillage deletion summary feature
Ticket Link
Fixes https://mattermost.atlassian.net/browse/MM-68626