Files
atomic-design-poc/docs/project/backlog/WP-58-openzaak-notifications.md
T
ehoandClaude Sonnet 5 f21c3c7ca2 docs(backlog): add phase 10 (OpenZaak hardening) and phase 11 (behandelportal)
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>
2026-07-30 11:59:11 +02:00

2.8 KiB

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

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).