Skip to content

Added docs for deletion summary feature#8933

Open
harshilsharma63 wants to merge 1 commit intomasterfrom
data_spillage_deletion_summary
Open

Added docs for deletion summary feature#8933
harshilsharma63 wants to merge 1 commit intomasterfrom
data_spillage_deletion_summary

Conversation

@harshilsharma63
Copy link
Copy Markdown
Member

Summary

Added docs for data spillage deletion summary feature

Ticket Link

Fixes https://mattermost.atlassian.net/browse/MM-68626

Copilot AI review requested due to automatic review settings May 4, 2026 12:35
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 4, 2026

📝 Walkthrough

Walkthrough

Updated 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.

Changes

Content Deletion and Reporting Documentation

Layer / File(s) Summary
Expanded Deletion Scope
source/administration-guide/manage/admin/content-flagging.rst (lines 93–107)
Replaced concise deletion description with a detailed enumeration of deleted data categories, including post records, file attachments, edit history revisions, priority metadata, notifications, acknowledgements, reminders, and thread/reply/reaction data.
Post Deletion Report Section
source/administration-guide/manage/admin/content-flagging.rst (lines 108–134)
Added comprehensive documentation of the Data Spillage Bot's delivery of auditable cleanup reports, including inline summary rendering, Markdown attachment naming, per-step status outcomes (Removed, Not applicable, Partial, Failed), and escalation guidance for partial or failed deletions.
Audit Retention Note
source/administration-guide/manage/admin/content-flagging.rst (lines 136–138)
Added note designating the post deletion report as the single source of truth for post-removal auditing and requiring retention of the reviewer thread per organizational audit policy.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title 'Added docs for deletion summary feature' accurately summarizes the main change: documentation updates for the deletion summary feature.
Description check ✅ Passed The description is directly related to the changeset, mentioning the data spillage deletion summary feature documentation and referencing a specific ticket.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch data_spillage_deletion_summary

Review rate limit: 4/5 reviews remaining, refill in 12 minutes.

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 560c09f and 11b87d2.

📒 Files selected for processing (1)
  • source/administration-guide/manage/admin/content-flagging.rst

Comment on lines +132 to +138
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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

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.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +96 to +100
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.
Comment on lines +104 to +106
- **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``.
Comment on lines +111 to +114
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.
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 4, 2026

Newest code from mattermost has been published to preview environment for Git SHA 11b87d2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants