S-09b · Approval flow — temp admin endpoint + status transition to projection #75

Open
opened 2026-07-13 14:03:38 +00:00 by not · 0 comments
Contributor

Split out of #10 (S-09). The walking skeleton currently has a single status (INGEDIEND) and no approval/status-transition path anywhere (domain is create-only, ACL creates zaken, the event-subscriber maps every zaak-create → INGEDIEND). The Openbaar portal (#10) is demoable against the existing public-safe BFF endpoint without this, so the approval flow is its own vertical slice.

Outcome: A behandelaar can approve a submitted registration via a temporary admin endpoint (no behandel-portal yet, that's S-12/#13). The approval transitions the zaak status; the new status flows via ACL → NRC → event-subscriber → projection, and the Openbaar register then shows the entry with the approved status.

Acceptance:

  • A new terminal/approved status (e.g. INGESCHREVEN) exists and is projected.
  • Temporary admin approve endpoint transitions a registration; status reaches the projection (via a real ZGW status set through the ACL — §8 keeps ZGW behind the ACL).
  • E2E: register via self-service (S-08) → approve via the admin endpoint → Openbaar register shows the entry as approved.
  • Mutation/unit coverage for the new projection status mapping.

Touches: services/domain, services/acl, services/event-subscriber, services/projection-api, e2e.

Out of scope: the behandel-portal UI (S-12), assessment logic (S-13), escalation (S-15).

Split out of #10 (S-09). The walking skeleton currently has a single status (`INGEDIEND`) and no approval/status-transition path anywhere (domain is create-only, ACL creates zaken, the event-subscriber maps every zaak-create → INGEDIEND). The Openbaar portal (#10) is demoable against the existing public-safe BFF endpoint without this, so the approval flow is its own vertical slice. **Outcome:** A behandelaar can approve a submitted registration via a **temporary admin endpoint** (no behandel-portal yet, that's S-12/#13). The approval transitions the zaak status; the new status flows via ACL → NRC → event-subscriber → projection, and the Openbaar register then shows the entry with the approved status. **Acceptance:** - A new terminal/approved status (e.g. `INGESCHREVEN`) exists and is projected. - Temporary admin approve endpoint transitions a registration; status reaches the projection (via a real ZGW status set through the ACL — §8 keeps ZGW behind the ACL). - E2E: register via self-service (S-08) → approve via the admin endpoint → Openbaar register shows the entry as approved. - Mutation/unit coverage for the new projection status mapping. **Touches:** `services/domain`, `services/acl`, `services/event-subscriber`, `services/projection-api`, e2e. **Out of scope:** the behandel-portal UI (S-12), assessment logic (S-13), escalation (S-15).
not added this to the Iteration 1 — Walking Skeleton milestone 2026-07-13 14:03:38 +00:00
not added the type:slicearea:aclarea:domainarea:event-subscriberarea:projection labels 2026-07-13 14:04:23 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: eho/register-referentie#75