WP-55..60 harden the OpenZaak integration for production (secrets/TLS, idempotent provisioning, least-privilege scopes, real notifications, confidentialiteit config, write-divergence resilience). WP-61..66 stand up a staff-facing behandelportal per ADR-0002, wired to the same backend via BFF-lite decision DTOs. Both phases are independent tracks; WP-60's Decisions block is deliberately left open for a planner-agent kickoff. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
69 lines
2.8 KiB
Markdown
69 lines
2.8 KiB
Markdown
# WP-58 — Real notifications (celery + scripted abonnement)
|
|
|
|
Status: todo
|
|
Phase: 10 — OpenZaak production hardening
|
|
|
|
## Why
|
|
|
|
The WP-54 harness deliberately trims celery/celery-beat/celery-flower and nginx, and sets
|
|
`NOTIFICATIONS_DISABLED: 'true'` — without a Celery worker, OpenZaak 500s and rolls back on
|
|
every write to a notified resource. Fine for a fixture-driven integration harness; a real
|
|
deployment that wants live Notificaties (WP-52's webhook) needs the workers running and the
|
|
`abonnement` (subscription) actually registered against the BFF's public callback URL —
|
|
today that registration step is manual.
|
|
|
|
## Read first
|
|
|
|
- `backend/openzaak/docker-compose.openzaak.yml` (top-of-file ponytail note)
|
|
- [openzaak-integration.md](../reference/openzaak-integration.md) (Notificaties section)
|
|
- [WP-52](WP-52-openzaak-notificaties.md)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- Add celery + celery-beat as additional compose services (same `openzaak/open-zaak`
|
|
image, different command), pointed at the same redis broker already in the harness.
|
|
- Registering the `abonnement` becomes a scripted, idempotent step — not a manual
|
|
admin-UI action — parameterized by the BFF's real public URL.
|
|
- Keep the existing WP-54 harness variant (`NOTIFICATIONS_DISABLED: 'true'`) available for
|
|
fast local iteration where a live webhook round-trip isn't needed; this WP is additive
|
|
(a "with notifications" profile/override), not a replacement.
|
|
|
|
## Files
|
|
|
|
- `backend/openzaak/docker-compose.openzaak.yml` (or an override file)
|
|
- New script/config for `abonnement` registration
|
|
- `docs/reference/openzaak-integration.md`
|
|
|
|
## Steps
|
|
|
|
1. Add celery/celery-beat services to a notifications-enabled compose profile.
|
|
2. Flip `NOTIFICATIONS_DISABLED` off for that profile.
|
|
3. Script the `abonnement` registration (POST to the NRC, pointed at the BFF's
|
|
`/zgw/notificaties` endpoint from WP-52), idempotent on rerun.
|
|
4. Verify a real write (e.g. a status change) triggers a live webhook delivery to the BFF.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] A notifications-enabled harness profile runs celery/celery-beat and delivers a real
|
|
notification end-to-end to the BFF's webhook.
|
|
- [ ] The `abonnement` registration step is a script, re-runnable without erroring on an
|
|
already-registered subscription.
|
|
|
|
## Verification
|
|
|
|
Bring up the notifications-enabled profile; create a zaak/status change; confirm the BFF's
|
|
`/zgw/notificaties` endpoint receives and logs it.
|
|
|
|
## Out of scope
|
|
|
|
Cache invalidation on notification receipt (flagged separately in
|
|
`openzaak-integration.md` as a `ponytail:` marker, not part of this slice);
|
|
celery-flower/monitoring UI.
|
|
|
|
## Risks
|
|
|
|
Celery/celery-beat add real operational surface (another process to keep alive) — scope
|
|
this WP to "works, documented," not a fully monitored deployment.
|
|
|
|
Depends on: WP-56 (provisioning mechanism this extends).
|