Retention "What applies to a path" never reports legal holds; hold paths are not validated (files has holds on "/Fall 1" and "/Spaces/Fall 1") #685

Closed
opened 2026-09-23 10:12:53 +00:00 by Cordy · 1 comment
Owner

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files). No settings were changed.

Where: Administration → Retention & holds.

1. Resolve ignores holds. The Retention tab's checker says "The deepest matching rule wins, and a legal hold beats every rule. Check a path before you rely on it." On files, Legal holds lists two active holds, on /Fall 1 and /Spaces/Fall 1 (placed 2026-08-10, reason "test"). Resolving /Fall 1, /Fall 1/x.pdf, /Spaces/Fall 1 and /Spaces/Fall 1/x.pdf each returns only "No retention rule covers this path · Automatic purging is off…", and never mentions a hold. An admin who "checks a path before relying on it" is told nothing about the strongest protection on it.

2. Hold paths aren't validated or normalised. The placeholder suggests /spaces/records-unit/case-2026-001 (lowercase spaces). The two existing holds use /Fall 1 (no namespace) and /Spaces/Fall 1 (capitalised). Both were accepted as-is, and neither obviously matches the canonical path of the "Fall 1" space. On files-bao, a hold on the storage form /home/nikola-test/_qa/qa-word.docx did work (delete and rename were refused), so the canonical form is the storage path. Those two holds likely protect nothing while the UI and the Overview ("2 legal holds active") present them as active. The Place hold form should resolve the path (exists? which namespace?) before accepting it, or warn "no such path".

Expected: Resolve shows "Legal hold: /… placed by … on …" for held paths; hold creation rejects or warns on paths that don't exist.
Seen: as above.

Screenshots: 685-resolve-ignores-holds.jpg (Resolve on /Spaces/Fall 1: no hold mentioned), 656-admin-holds.jpg (the two holds).

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files). No settings were changed. **Where:** Administration → Retention & holds. **1. Resolve ignores holds.** The Retention tab's checker says "The deepest matching rule wins, and **a legal hold beats every rule**. Check a path before you rely on it." On files, Legal holds lists two active holds, on `/Fall 1` and `/Spaces/Fall 1` (placed 2026-08-10, reason "test"). Resolving `/Fall 1`, `/Fall 1/x.pdf`, `/Spaces/Fall 1` and `/Spaces/Fall 1/x.pdf` each returns only "No retention rule covers this path · Automatic purging is off…", and never mentions a hold. An admin who "checks a path before relying on it" is told nothing about the strongest protection on it. **2. Hold paths aren't validated or normalised.** The placeholder suggests `/spaces/records-unit/case-2026-001` (lowercase `spaces`). The two existing holds use `/Fall 1` (no namespace) and `/Spaces/Fall 1` (capitalised). Both were accepted as-is, and neither obviously matches the canonical path of the "Fall 1" space. On files-bao, a hold on the storage form `/home/nikola-test/_qa/qa-word.docx` did work (delete and rename were refused), so the canonical form is the storage path. Those two holds likely protect nothing while the UI and the Overview ("2 legal holds active") present them as active. The Place hold form should resolve the path (exists? which namespace?) before accepting it, or warn "no such path". **Expected:** Resolve shows "Legal hold: /… placed by … on …" for held paths; hold creation rejects or warns on paths that don't exist. **Seen:** as above. **Screenshots:** `685-resolve-ignores-holds.jpg` (Resolve on `/Spaces/Fall 1`: no hold mentioned), `656-admin-holds.jpg` (the two holds).
Author
Owner

Stronger evidence: Deleted files → Purge log on files shows 2026-08-19 20:51 · Manual · /spaces/Fall 1 · by nikola-test. The canonical path is /spaces/Fall 1 (lowercase), and that space was purged on 08-19 while the holds on /Fall 1 and /Spaces/Fall 1 (placed 08-10) were "active". So the mis-spelled holds really did protect nothing, and they still show as active holds today. Screenshot: 656-admin-trash-log.jpg.

Stronger evidence: Deleted files → **Purge log** on files shows `2026-08-19 20:51 · Manual · /spaces/Fall 1 · by nikola-test`. The canonical path is `/spaces/Fall 1` (lowercase), and that space was **purged on 08-19 while the holds on `/Fall 1` and `/Spaces/Fall 1` (placed 08-10) were "active"**. So the mis-spelled holds really did protect nothing, and they still show as active holds today. Screenshot: `656-admin-trash-log.jpg`.
Cordy closed this issue 2026-09-23 19:11:22 +00:00
Sign in to join this conversation.
No labels
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#685
No description provided.