3 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	5807937229	feat(zgw): OpenZaak Documenten (DRC) upload + zaak link (WP-51) ... Extends the OpenZaak seam with IDocumentSource, sibling of IZaakSource (WP-49/50): an upload always lands locally first (DocumentStore stays the record of truth for preview/download/audit) and, when Zgw:Enabled=true, is also registered as a DRC enkelvoudiginformatie- object; once a zaak exists (IZaakSource.CreateZaak now also returns its ZaakUrl), submit links each document to it via zaakinformatie- object. FE upload/list DTOs are unchanged. - ZgwOptions gains DrcBaseUrl + a category->informatieobjecttype URL map (the document analogue of ZaaktypeUrls). - LocalDocumentSource is the same DocumentStore.Add/Link calls the endpoints used to make inline — zero behaviour change offline. - OpenZaakDocumentSource POSTs the eio then the zaak link, persisting the DRC url (DocumentStore.SetDrcUrl) so linking doesn't re-upload. - Factored the GET/POST-with-bearer-JWT plumbing shared with OpenZaakZaakSource into ZgwHttpClient; shared the stub handler between the two source test classes as ZgwStubHandler. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-29 20:54:31 +02:00
ehoandClaude Sonnet 5	de3bff0d7f	feat(zgw): OpenZaak create-zaak, first write slice (WP-50) ... Extends the IZaakSource seam (WP-49, read-only) with CreateZaak: submitting an aanvraag now also registers a Zaak + Status + Rol in OpenZaak when Zgw:Enabled=true, routed through the existing /applications/{id}/submit endpoint with the FE response DTO unchanged (ADR-0001/ADR-0005 — the endpoint never branches on the config flag itself, DI already picked the implementation). - ZgwOptions gains a Type→zaaktype-URL map + the two RSINs a Zaak needs. - LocalZaakSource.CreateZaak is a pure passthrough of what the endpoint already computes locally (zero behaviour change for the offline default). - OpenZaakZaakSource.CreateZaak POSTs the zaak (identificatie = the same local reference, so both stay in sync), resolves + POSTs the initial status and the initiator rol (BSN) via Catalogi lookups, and maps the result back into the submit response. - Marked ponytail shortcuts: first-statustype/roltype-Catalogi-returns (no per-type config) and no compensating transaction on partial failure — both fine for a first slice against a demo backend. Verified: full `npm run ci` green, zero api-client drift, 144/144 backend tests (142 existing + 2 new stub-handler tests asserting the POST bodies + type→zaaktype mapping per the acceptance criteria). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-29 09:03:13 +02:00
ehoandClaude Opus 4.8	1c3c195d32	feat(backend): expand stamdata + OpenZaak-ready cases seam (WP-49) ... Stamdata: add beroepen, opleidingen (temporal), and specialismen tables to the schema-driven catalog (zero UI code). opleidingen.beroep and specialismen.beroep both reference beroepen.code — the first stamdata->stamdata references, enforced by two new StamdataRef entries in the CI gate. OpenZaak/ZGW (WP-49, slice 1 — read-only zaken): introduce IZaakSource as the cases read seam. Default LocalZaakSource reads the local SQLite store (offline); an OpenZaakZaakSource (Zgw/ client: HS256 per-call JWT, ZGW->existing-DTO mapper, paginating HTTP source) is selected behind Zgw:Enabled (default false). The FE never changes — same ApplicationSummaryDto, no api-client drift. Unit-tested with fixtures + a stub HttpMessageHandler; no live OpenZaak needed. Docs: ADR-0005, reference/openzaak-integration.md, WP-49..52 roadmap, stamdata.md update, README index rows. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-24 15:01:06 +02:00