ehoandClaude Sonnet 5
f21c3c7ca2
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>
74 lines
3.1 KiB
Markdown
74 lines
3.1 KiB
Markdown
# 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
|
|
|
|
1. Express the catalogus/zaaktype/statustype/roltype definitions currently created by
|
|
curl as `setup_configuration` YAML.
|
|
2. Wire it into the `web-init` command alongside the existing JWTSecret/Applicatie config.
|
|
3. Trim `bootstrap-catalogus.sh` to only what setup_configuration can't cover, if anything.
|
|
4. Test: tear down + `docker compose up` twice in a row (fresh volume, then existing
|
|
volume); confirm no failure on rerun.
|
|
5. 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.
|