5 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	8560746d15	refactor: strip WP-/RB- ticket refs from backend (RD-19) ... The backend half of the sweep RD-18 did for the front end. git blame holds the provenance and stays correct when the code moves; the comment names a closed ticket and tells the reader nothing the sentence around it does not. public/letter.css and LetterHtml.golden.html change together, because the renderer inlines the CSS and the golden file snapshots the result. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-04 21:48:08 +02:00
ehoandClaude Opus 5	6cfd70eeeb	fix(backend): resolve besluit endpoint's id via Referentie, not local PK ... POST /beoordeling/{id}/besluit always 404'd against a real OpenZaak: {id} is the FE-facing case id from IZaakSource.ListCases, which under OpenZaakZaakSource is the ZGW zaak's own uuid, not ApplicationStore's primary key. Resolve the case through ListCases first (same seam the GET sibling already uses), then to the local Aanvraag via its Referentie — the one identifier stable across both sources. Adds ApplicationStore.GetByReferentie and a regression test that reproduces the divergence with a decorating IZaakSource test double instead of a live OpenZaak. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-05 15:20:36 +02:00
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	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