4 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	1e87997ea0	feat(openzaak): least-privilege client scopes (WP-57) ... setup_configuration has no YAML field for granular autorisaties, so bigregister-test now starts at heeft_alle_autorisaties: false (dev + prod template) and bootstrap-catalogus.sh grants exactly the ztc/zrc scopes the harness needs via the Django ORM, sidestepping the zero-scope chicken-and-egg with the JWT-authenticated Autorisaties REST API. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 14:05:54 +02:00
ehoandClaude Sonnet 5	89ad3490b0	feat(openzaak): idempotent catalogus/zaaktype/zaak provisioning (WP-56) ... bootstrap-catalogus.sh now looks up every resource by its natural key before creating it (catalogus by domein+rsin, zaaktype by catalogus+identificatie, statustype by zaaktype+volgnummer, roltype by zaaktype+omschrijvingGeneriek, zaaktype-publish by checking `concept` first, zaak by identificatie, status/rol by existence-under-the-zaak), so rerunning against an already-seeded instance reuses what's there instead of erroring. The WP's original plan (move this into OpenZaak's `setup_configuration` mechanism) turned out not to be achievable: reading the actual django_setup_configuration steps installed inside the open-zaak image shows no step exists for Catalogi/Zaken content anywhere in this OpenZaak version — only sites/credentials/applicaties/selectielijst. Documented as a deviation; the WP's own Risks section already anticipated this and sanctioned falling back to an idempotent script. Verified live: fresh instance -> full run (all created) -> integration test green -> reran the script twice more against the same instance (all reused, identical URLs, no duplicates) -> integration test still green. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 12:57:37 +02:00
ehoandClaude Sonnet 5	3588057a75	feat(openzaak): real secrets + TLS for the production OpenZaak harness (WP-55) ... docker-compose.openzaak.prod.yml layers real SECRET_KEY/DB password/site domain/allowed-hosts (all required, fail-fast via ${VAR:?...}) on top of the WP-54 dev harness, switches Postgres off trust auth, and sets IS_HTTPS for a front-facing reverse-proxy TLS setup. The ZGW client secret lives inside a file setup_configuration reads rather than a compose env var, so it's templated (data.prod.yaml.template, no secret) and rendered host-side via render-prod-secrets.sh into a gitignored data.prod.yaml, mounted over the container's dev data.yaml. ZgwOptions.cs already binds from IConfiguration, so the BFF side needed no code change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 12:27:21 +02:00
ehoandClaude Sonnet 5	5cb3e1a9f0	feat(zgw): docker OpenZaak integration-test harness (WP-54) ... Opt-in docker-compose (postgres+redis+OpenZaak, no celery/nginx) + bootstrap-catalogus.sh seed a real OpenZaak instance; OpenZaakIntegrationTests (Category=Integration, excluded from default dotnet test/CI) proves the ZGW seam against it for the first time. That live run caught a real bug: ZgwHttpClient never sent Content-Crs/Accept-Crs headers, so every write would 412 against a spec-compliant OpenZaak — fixed alongside the harness. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-30 09:08:35 +02:00