ehoandClaude Opus 5
12f17d9d73
Two backlog trees are complete: `docs/project/backlog/` (75 files, every WP done) and `docs/project/refactor-backlog-setup/` (the arc before it). Move both under `docs/project/archive/` with `git mv`, so history stays intact through `git log --follow`. `SHOWCASE-ROADMAP.md` moves with them, because it points at the now-archived backlog README. Add `docs/project/archive/README.md`. It states that these trees are historical and names the two directories that are still live. Repoint every inbound reference named in RD-30's Files table: CLAUDE.md, the root README, both backend READMEs, `LetterHtml.cs`, `a11y.mdx`, the `document-feature` and `new-ssp` skills, and the readable-codebase PLAN, README, and RD-19 ticket. Fix two upward-relative links inside the moved WP files (WP-68, WP-69) that gained a directory level and would otherwise break. Repoint `.prettierignore`'s two agent-prompt exclusions to their new path, so prettier keeps leaving those files' exact wording alone. Mark RD-30 done and check off its acceptance criteria; flip its README row to done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
WP-36 — Admin cases page + admin delete
Status: done Phase: 7 — refinements
Why
Admins can maintain stamdata and org-templates but have no view of the cases (aanvragen) in the register, and no way to remove an erroneous one. This WP adds an admin-only overview of all cases across owners and an admin delete that can remove any case — the back-office counterpart of the user's own dashboard.
Decisions (made while building — no spec existed; flagged for review)
- Single capability
cases:managecovers both the list and the delete (one back-office concern), following theorgtemplate:edit/stamdata:editprecedent exactly (Authz role→cap + aCanManageCasesgate + aCasesAdmin(ctx,…)helper; FECapabilityunion +me.adapterKNOWN+capabilityGuard+ nav item +role.interceptorprefix). - Page lives in
registratie(notbeheer).registratieowns theAanvraagaggregate, so the admin view reuses itsaanvraag-viewlabels +parseApplicationstrust boundary instead of duplicating them — and it respects the layer boundary (beheermay not importregistratie). This matches the existing pattern (stamdata-admin lives inbeheerbecausebeheerowns stamdata; org-template-admin inbrief). Routed at/beheer/zakenfor a legible admin URL. - Admin delete removes ANY case — any owner, submitted or not — unlike the user-facing
DELETE /applications/{id}(owner-scoped, 409 on a submitted case). That is the admin power. - Native
confirm()guards the delete. No confirm-dialog component exists (the only precedent is a nativeconfirm()in behandel-scherm); the delete is irreversible, so it gets a prompt rather than the dashboard's no-confirm optimistic cancel. - Single owner in practice. Only
DemoOwnerexists, so the list shows that owner's cases with an Owner column; no fake multi-user seed was added (the endpoint is cross-owner-capable —ListAll()— so real multi-owner data would just appear).
Files
- Backend:
ApplicationStore.ListAll()+DeleteAny(id);ApplicationSummaryDto.Owner+ToAdminSummaryDto;Authzcap +CanManageCases;Program.csCasesAdmingate +GET /admin/cases+DELETE /admin/cases/{id};AdminCasesTests(+ update the org-template/mecap-list assertion). SQLite can'tORDER BY DateTimeOffset→ListAllsorts client-side. - FE:
capability.ts+me.adapterKNOWN+role.interceptor(/api/v1/admin/cases);aanvraag.tsowner?;applications.adapterlistAll/deleteAny+ parse owner;registratie/application/admin-cases.store.ts(+spec);registratie/ui/admin-cases.page.ts; route inapp.routes.ts; nav item insite-header; new$localizeids + English targets.
Acceptance criteria
- Admin-only page at
/beheer/zakenlists all cases (owner + type + status), gated bycases:manage(denial alert for non-admins; server re-enforces viaCasesAdmin). - Admin delete removes any case (incl. submitted); confirmed, optimistic with rollback.
npm run cigreen (336 FE tests, backend 129, localized build, drift clean after commit).