CI / frontend (push) Successful in 2m59s
CI / backend (push) Successful in 1m27s
CI / semgrep (push) Successful in 58s
CI / e2e (push) Successful in 2m30s
CI / api-client-drift (push) Canceled after 1m14s
CI / storybook-a11y (push) Canceled after 29m8s
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>
52 lines
1.7 KiB
Markdown
52 lines
1.7 KiB
Markdown
# WP-52 — OpenZaak Notificaties (NRC) live status
|
|
|
|
Status: todo
|
|
Phase: 9 — OpenZaak / ZGW integration
|
|
|
|
## Why
|
|
|
|
With cases in OpenZaak, case status changes in the backoffice, not in this app. Production
|
|
"live" status needs the **Notificaties API (NRC)**: subscribe to zaak events and update on
|
|
webhook, rather than polling. Last slice of the ZGW integration arc.
|
|
|
|
## Read first
|
|
|
|
- [openzaak-integration.md](../reference/openzaak-integration.md)
|
|
- WP-49/50/51 (the read/write/document slices this builds on)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- The BFF exposes a webhook endpoint that NRC calls; it validates an Authorization header the
|
|
BFF issued, then invalidates any cached case data / notifies the FE.
|
|
- Subscription (`abonnement` on the `zaken` kanaal) is provisioning/config, not runtime code.
|
|
- FE update mechanism reuses the existing RemoteData reload — no new FE contract.
|
|
|
|
## Files
|
|
|
|
- A new BFF webhook endpoint (`POST /zgw/notificaties`) + Authorization validation.
|
|
- `ZgwOptions`: `NrcBaseUrl` + the webhook shared secret.
|
|
|
|
## Steps
|
|
|
|
1. Add the webhook endpoint (auth-checked, no PII logged — reuse the audit seam).
|
|
2. On a zaak event, invalidate cache / push an update to the FE.
|
|
3. Document the `abonnement` provisioning (out-of-band, one-time).
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] A posted NRC event (correct auth) triggers a case refresh; a bad-auth post is rejected.
|
|
- [ ] No PII in the webhook logs.
|
|
- [ ] Tests cover auth accept/reject + the refresh trigger.
|
|
|
|
## Verification
|
|
|
|
`dotnet test`; against a docker OpenZaak + NRC if available.
|
|
|
|
## Out of scope
|
|
|
|
Full event fan-out / real-time push infra beyond a simple cache-invalidation + reload.
|
|
|
|
## Risks
|
|
|
|
Webhook must be reachable from NRC in prod (network/ingress) — a deployment concern, not code.
|