eho/atomic-design-poc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(backend): resolve besluit endpoint's id via Referentie, not local PK

Browse Source 
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>
This commit is contained in:
eho
2026-08-05 15:20:36 +02:00
co-authored by Claude Opus 5
parent d2c2cffc1f
commit 6cfd70eeeb
12 changed files with 310 additions and 63 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/openzaak-integration.md
+14 -11
View File
@@ -175,10 +175,13 @@ JWT's audit claims reflect the behandelaar, not a static identity.
ontbreekt"). This was missing until WP-54's live harness caught it — the stub-handler tests
never modelled the header, so it had shipped silently since WP-49/50.
- `ZgwZaakMapper.cs` — the anti-corruption map: ZGW Zaak → `ApplicationSummaryDto`. This is
where **URL identity** becomes the trailing uuid and the **zaaktype URL** is resolved to a
human label (the cross-service join).
- `OpenZaakZaakSource.cs` — follows `{count,next,previous,results}` pagination, resolves +
caches zaaktype labels, attaches `Authorization: Bearer <jwt>`.
where **URL identity** becomes the trailing uuid; `Type` takes the internal aanvraag-type
key (`AanvraagTypeFor`, below) — a real bug (found via a live behandelportal walkthrough,
fixed post-WP-66) had this carrying OpenZaak's human zaaktype label instead, which the FE's
`AANVRAAG_TYPES` trust boundary always rejected.
- `OpenZaakZaakSource.cs` — follows `{count,next,previous,results}` pagination, maps each
zaak's zaaktype URL back to the internal key via `Zgw:ZaaktypeUrls` (`AanvraagTypeFor` — a
local lookup, no Catalogi round-trip), attaches `Authorization: Bearer <jwt>`.
- `OpenZaakDocumentSource.cs` — DRC upload + zaak-link (WP-51), same auth/JSON pattern.
- `NotificatieDto.cs` + the `POST /api/v1/zgw/notificaties` endpoint (`Program.cs`, WP-52) — the
**inbound** NRC webhook, not a source/mapper: see the dedicated section below.
@@ -272,13 +275,13 @@ flag, never a rollen matrix.
## The five ZGW APIs (context for later slices)
| API | Component | Used by |
| ------------ | --------- | --------------------------------------------------- |
| Zaken | ZRC | slice 1 (read), WP-50 (create) |
| Catalogi | ZTC | slice 1 (zaaktype label; also type URLs for create) |
| Documenten | DRC | WP-51 (upload + zaak↔document link) |
| Besluiten | BRC | later (formal decisions) |
| Notificaties | NRC | WP-52 (live status via webhooks, not polling) |
| API | Component | Used by |
| ------------ | --------- | ---------------------------------------------------------------- |
| Zaken | ZRC | slice 1 (read), WP-50 (create) |
| Catalogi | ZTC | WP-50/66 (statustype/roltype/resultaattype for create + besluit) |
| Documenten | DRC | WP-51 (upload + zaak↔document link) |
| Besluiten | BRC | later (formal decisions) |
| Notificaties | NRC | WP-52 (live status via webhooks, not polling) |
## How to add the next slice