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>
84 lines
3.9 KiB
Markdown
84 lines
3.9 KiB
Markdown
# WP-59 — Per-document-type confidentialiteit config
|
|
|
|
Status: done
|
|
Phase: 10 — OpenZaak production hardening
|
|
|
|
## Why
|
|
|
|
`OpenZaakDocumentSource` hardcodes `vertrouwelijkheidaanduiding` to `"openbaar"` for every
|
|
uploaded document, regardless of document type. Real BIG-register documents (diploma's, ID
|
|
scans) plausibly need different confidentiality levels. This repo already has a house
|
|
pattern for exactly this kind of business-tunable value — stamdata-as-code (ADR-0004) — so
|
|
this slice is "apply the existing pattern," not invent a new one.
|
|
|
|
## Read first
|
|
|
|
- [ADR-0004 — Stamdata as code](../reference/architecture/0004-stamdata-as-code.md)
|
|
- `backend/src/BigRegister.Api/Stamdata/` (an existing table for the shape to imitate)
|
|
- `backend/src/BigRegister.Api/Zgw/OpenZaakDocumentSource.cs`
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- Confidentiality level is keyed by document type (whatever type already distinguishes
|
|
uploads, e.g. diploma vs. id-bewijs) via a new Stamdata table, using the existing
|
|
`StamdataTable.Of<T>` mechanism — not a new ad hoc config format.
|
|
- Default/fallback value stays `"openbaar"` if a document type isn't in the table, to
|
|
avoid a silent upload failure.
|
|
|
|
## Files
|
|
|
|
- `Stamdata/` (new table + validation)
|
|
- `Zgw/OpenZaakDocumentSource.cs`
|
|
- `StamdataCatalog.cs` (register the new table)
|
|
|
|
## Steps
|
|
|
|
1. Add a `DocumentConfidentialiteit` stamdata table (document type →
|
|
vertrouwelijkheidaanduiding), validated at build like every other stamdata table
|
|
(`StamdataValidationTests`).
|
|
2. Register it in `StamdataCatalog` so it's editable via the existing `/beheer/stamdata`
|
|
grid.
|
|
3. `OpenZaakDocumentSource` looks up the level by document type instead of hardcoding
|
|
`"openbaar"`.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [x] Confidentiality level for a real upload varies by document type per the new
|
|
stamdata table (`identiteit` → `vertrouwelijk`; everything else → `openbaar`).
|
|
- [x] `StamdataValidationTests` cover the new table (a bad edit fails CI, per ADR-0004).
|
|
- [x] `/beheer/stamdata` can edit the new table without a code change (existing generic
|
|
editor — the `StamdataCatalog` registration is the only wiring needed).
|
|
|
|
## What actually happened
|
|
|
|
Implemented mostly as planned — one gap found and closed: the diff as first written
|
|
registered `DocumentConfidentialiteit` in `StamdataCatalog` and wired the lookup into
|
|
`OpenZaakDocumentSource`, plus a positive test (`identiteit` → `vertrouwelijk`) and a
|
|
fallback test (an unmapped category, `org-logo`, → `openbaar`), but had **no**
|
|
`StamdataValidationTests` reference-integrity entry for the new table — the second
|
|
acceptance box was unchecked. Added one: a `StamdataRef` resolving every
|
|
`documentconfidentialiteit.json` `categoryId` against the real set of document category
|
|
ids (`DocumentRules.AllCategoriesFor` across `registratie`/`herregistratie`/`org-template`),
|
|
so a typo'd or stale `categoryId` now fails the build instead of silently never matching
|
|
(`OpenZaakDocumentSource.ConfidentialiteitFor`'s dictionary lookup would otherwise just
|
|
fall back to `"openbaar"` forever with no signal). `org-logo` deliberately stays absent
|
|
from the confidentialiteit table (falls back to `"openbaar"`) and correctly still
|
|
resolves as a known category — the reference check validates "is this a real category",
|
|
not "must every category be configured."
|
|
|
|
## Verification
|
|
|
|
`cd backend && dotnet test` (161/161 green, incl. the 2 new `OpenZaakDocumentSourceTests` plus
|
|
the new `StamdataValidationTests` reference entry); `dotnet format --verify-no-changes` clean.
|
|
Manual: `/beheer/stamdata` shows and edits the new table; an upload for a mapped document type
|
|
carries the mapped confidentiality level (test asserted).
|
|
|
|
## Out of scope
|
|
|
|
Any UI-facing confidentiality display/change on the citizen side (FE keeps rendering
|
|
decisions, not recomputing them, per ADR-0001).
|
|
|
|
## Risks
|
|
|
|
None significant — this is a config/data-shape change reusing an established mechanism.
|