Legal hold "Lift" acts on a single click — no confirmation, no reason captured #683

New issue

Closed

opened 2026-09-23 10:09:17 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-23 10:09:17 +00:00

Owner

Found by the #656 QA pass (v0.6.247, files-bao).

Matrix row: §9 Admin — "Legal holds | Hold a path; try delete/rename as admin | Refused until lifted". The row itself passes: while the hold was active on /home/nikola-test/_qa/qa-word.docx, the list showed an "On hold" chip, and Delete and Rename as admin were refused with "…failed: legal hold: this content is protected until the hold is lifted".

Finding: Retention & holds → Legal holds → Lift removes the hold immediately. There is no confirmation dialog and no prompt for a reason. The hold simply disappears from "Active holds" ("No active holds.").

Expected (style guide, Dialogs canon: irreversible actions confirm with a fact-row dialog): lifting a legal hold is the most consequential action on this page. The page's own copy stresses that the reason "is the only record of why, and whoever lifts the hold in two years will not be you". A confirm dialog that names the path, shows who placed the hold and why, and asks for a lift reason (recorded in the audit event) would match that. The page places holds with a reason field, but lifts them with none.

Adjacent notes, not filed separately:

The file row menu still offers Edit in Collabora, Rename, Move and Delete on a held file. The server refuses correctly, but the menu could grey these out, as the chip already knows the state.
Space delete (spacedeldlg) does this well: a fact list plus type-to-confirm. That is the pattern to copy here.

Screenshot: none. The state was transient (placed at 10:08Z and lifted a minute later). The audit log has both events.

Found by the #656 QA pass (v0.6.247, files-bao). **Matrix row:** §9 Admin — "Legal holds | Hold a path; try delete/rename as admin | Refused until lifted". The row itself **passes**: while the hold was active on `/home/nikola-test/_qa/qa-word.docx`, the list showed an "On hold" chip, and Delete and Rename as admin were refused with "…failed: legal hold: this content is protected until the hold is lifted". **Finding:** Retention & holds → Legal holds → **Lift** removes the hold immediately. There is no confirmation dialog and no prompt for a reason. The hold simply disappears from "Active holds" ("No active holds."). **Expected (style guide, Dialogs canon: irreversible actions confirm with a fact-row dialog):** lifting a legal hold is the most consequential action on this page. The page's own copy stresses that the reason "is the only record of why, and whoever lifts the hold in two years will not be you". A confirm dialog that names the path, shows who placed the hold and why, and asks for a lift reason (recorded in the audit event) would match that. The page places holds *with* a reason field, but lifts them with none. Adjacent notes, not filed separately: - The file row menu still offers Edit in Collabora, Rename, Move and Delete on a held file. The server refuses correctly, but the menu could grey these out, as the chip already knows the state. - Space delete (spacedeldlg) does this well: a fact list plus type-to-confirm. That is the pattern to copy here. **Screenshot:** none. The state was transient (placed at 10:08Z and lifted a minute later). The audit log has both events.