Files
atomic-design-poc/docs/project/archive/backlog/WP-59-document-confidentialiteit-config.md
ehoandClaude Opus 5 12f17d9d73 docs: archive the finished backlogs (RD-30)
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>
2026-09-08 23:00:38 +02:00

3.9 KiB

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
  • 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

  • Confidentiality level for a real upload varies by document type per the new stamdata table (identiteitvertrouwelijk; everything else → openbaar).
  • StamdataValidationTests cover the new table (a bad edit fails CI, per ADR-0004).
  • /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 (identiteitvertrouwelijk) 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.