Files

T

ehoandClaude Sonnet 5 f21c3c7ca2 docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)

WP-55..60 harden the OpenZaak integration for production (secrets/TLS,
idempotent provisioning, least-privilege scopes, real notifications,
confidentialiteit config, write-divergence resilience). WP-61..66 stand up
a staff-facing behandelportal per ADR-0002, wired to the same backend via
BFF-lite decision DTOs. Both phases are independent tracks; WP-60's
Decisions block is deliberately left open for a planner-agent kickoff.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-30 11:59:11 +02:00

3.1 KiB

Raw Blame History

WP-56 — Idempotent catalogus provisioning

Status: todo Phase: 10 — OpenZaak production hardening

Why

backend/openzaak/bootstrap-catalogus.sh seeds catalogus/zaaktype/statustype/roltype/zaak via hand-rolled curl+JWT and is explicitly not idempotent (fails on domein+rsin uniqueness on rerun) — fine for a one-shot WP-54 harness, wrong for an environment that needs to be rebuildable. OpenZaak already ships a documented, scripted alternative — the setup_configuration mechanism (already used in the harness for the JWTSecret/Applicatie, see setup_configuration/data.yaml) — this WP extends that same mechanism to the catalogus content too.

Read first

backend/openzaak/bootstrap-catalogus.sh
backend/openzaak/setup_configuration/data.yaml
backend/openzaak/docker-compose.openzaak.yml (web-init service)
OpenZaak's own setup_configuration / openzaak_config_cli docs (upstream)

Decisions (pre-made, don't relitigate)

Move catalogus/zaaktype/statustype/roltype provisioning into setup_configuration, run by the existing web-init one-shot service, instead of the separate curl script.
Keep bootstrap-catalogus.sh only for whatever content setup_configuration genuinely can't express (e.g. a demo zaak instance) — confirm what's left at kickoff.
Provisioning must be safe to run against an already-provisioned instance — either genuinely idempotent, or the compose is structured to only run it once per fresh volume (document which, don't leave it ambiguous).

Files

backend/openzaak/setup_configuration/data.yaml
backend/openzaak/bootstrap-catalogus.sh (trim to whatever remains)
backend/openzaak/docker-compose.openzaak.yml
backend/openzaak/README.md

Steps

Express the catalogus/zaaktype/statustype/roltype definitions currently created by curl as setup_configuration YAML.
Wire it into the web-init command alongside the existing JWTSecret/Applicatie config.
Trim bootstrap-catalogus.sh to only what setup_configuration can't cover, if anything.
Test: tear down + docker compose up twice in a row (fresh volume, then existing volume); confirm no failure on rerun.
Update the README describing the provisioning flow.

Acceptance criteria

Catalogus/zaaktype/statustype/roltype provisioning is declarative (setup_configuration), not imperative curl.
Running the compose stack up twice in a row doesn't error.
WP-54's OpenZaakIntegrationTests still pass unchanged (same content, different provisioning mechanism).

Verification

docker compose -f backend/openzaak/docker-compose.openzaak.yml up twice in a row (fresh volume, then existing volume); cd backend && dotnet test --filter Category=Integration against the harness.

Out of scope

Secrets/TLS (WP-55, unrelated but sequenced first in the table only by number), client scopes (WP-57), notifications (WP-58).

Risks

OpenZaak's setup_configuration coverage for zaaktype/besluittype content may be incomplete upstream — if a piece genuinely can't be expressed declaratively, keep it in a clearly-labeled idempotent script rather than forcing a bad fit.

3.1 KiB Raw Blame History