Epic: "Deleted files" admin topic — trash retention, manual purge, purge log #278

New issue

Closed

opened 2026-08-19 18:43:29 +00:00 by Cordy · 0 comments

Cordy commented

2026-08-19 18:43:29 +00:00

Owner

Context

The #268 decisions made the trash subsystem a first-class part of the deletion story (space deletion routes contents through trash; the name-tombstone window equals the trash retention window; group keys retire at final purge). Dogfood re-read (2026-08-19, Nikola): the trash lifecycle deserves its own administrative surface instead of being an implicit background behavior.

Scope

A new Administration topic "Deleted files" (same vocabulary as the user-facing left-nav entry; working alternative considered and rejected: "Trash settings") under the Instance section, deep-linkable as #admin/trash, with three tabs:

Retention (#279) — admin-set trash retention before final deletion (bounded choice, e.g. 1–X months, operator decides X), a deliberate checkbox to disable final deletion entirely (items stay until manually purged), and the Auto-purge tab relocated here from Retention & holds (it is trash behavior, not retention policy; Retention & holds keeps Retention + Legal holds).
Manual purge (#280) — deliberately and permanently delete items from the trash from the admin page: browse/filter trash contents, per-item and bulk purge with type-to-confirm, legal-hold interlock (refuse-on-conflict).
Purge log (#281) — a queryable log of finally-deleted files (written at final deletion, whether automatic or manual), so "what left the system, when, and why" survives the data itself.

Design constraints (inherited)

Legal holds always block purge — automatic and manual alike.
The #268 space-name tombstone window is defined as this trash retention window; changing retention changes tombstones for future deletions (document the interaction).
"Disable final deletion" means retention still marks items as expired-eligible but nothing purges; the Retention tab must show a visible warning that trash then grows unbounded (quota interaction!).
Settings persist in the settings store (state-backend), enforced server-side at the purge chokepoint — the admin UI is presentation only, consistent with the #255 audit stance.
Purge events also append to the audit log (trash-purge action); the Purge log tab is the trash-scoped view of that record.

Process

Per-issue, implementation starts with a frontend-design mockup/wireframe proposal for sign-off before the ship (house process going forward for UI-touching issues).

Children: #279 (retention settings + backend enforcement + auto-purge relocation), #280 (manual purge surface), #281 (purge log). Work starts 2026-08-19.

## Context The #268 decisions made the trash subsystem a first-class part of the deletion story (space deletion routes contents through trash; the name-tombstone window equals the trash retention window; group keys retire at final purge). Dogfood re-read (2026-08-19, Nikola): the trash lifecycle deserves its own administrative surface instead of being an implicit background behavior. ## Scope A new Administration topic **"Deleted files"** (same vocabulary as the user-facing left-nav entry; working alternative considered and rejected: "Trash settings") under the Instance section, deep-linkable as `#admin/trash`, with three tabs: 1. **Retention** (#279) — admin-set trash retention before final deletion (bounded choice, e.g. 1–X months, operator decides X), a deliberate checkbox to **disable final deletion entirely** (items stay until manually purged), and the **Auto-purge tab relocated here** from Retention & holds (it is trash behavior, not retention policy; Retention & holds keeps Retention + Legal holds). 2. **Manual purge** (#280) — deliberately and permanently delete items from the trash from the admin page: browse/filter trash contents, per-item and bulk purge with type-to-confirm, legal-hold interlock (refuse-on-conflict). 3. **Purge log** (#281) — a queryable log of finally-deleted files (written at final deletion, whether automatic or manual), so "what left the system, when, and why" survives the data itself. ## Design constraints (inherited) - Legal holds always block purge — automatic and manual alike. - The #268 space-name tombstone window is defined as this trash retention window; changing retention changes tombstones for *future* deletions (document the interaction). - "Disable final deletion" means retention still *marks* items as expired-eligible but nothing purges; the Retention tab must show a visible warning that trash then grows unbounded (quota interaction!). - Settings persist in the settings store (state-backend), enforced server-side at the purge chokepoint — the admin UI is presentation only, consistent with the #255 audit stance. - Purge events also append to the audit log (`trash-purge` action); the Purge log tab is the trash-scoped view of that record. ## Process Per-issue, implementation starts with a frontend-design mockup/wireframe proposal for sign-off before the ship (house process going forward for UI-touching issues). Children: #279 (retention settings + backend enforcement + auto-purge relocation), #280 (manual purge surface), #281 (purge log). Work starts 2026-08-19.