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

Merged

not merged 13 commits from feat/75-approval-flow into main 2026-07-14 09:05:00 +00:00

Conversation 0 Commits 13 Files Changed 36 +1109 -32

not commented 2026-07-13 15:06:25 +00:00

Contributor

Copy Link

What & why

S-09b (#75, split from #10) — the approval flow that completes the walking skeleton. A behandelaar can now approve a submitted registration; the entry flips from INGEDIEND to INGESCHREVEN in the public register. Flow: POST /registrations/{id}/approve (domain) → ACL sets the zaak eindstatus (ZGW /statussen) → OpenZaak → NRC → event-subscriber → projection → openbaar.

Changes (bottom-up, each red→green TDD)

• Domain — RegistrationStatus.Ingeschreven + Registration.Approve() (guards: opened zaak, only from INGEDIEND); ApproveRegistration use case (idempotent) + temp POST /registrations/{id}/approve endpoint; IAclClient.ApproveZaakAsync.
• ACL — resolves the zaaktype's eindstatus from the catalogus (isEindstatus / highest volgnummer) and POSTs a ZGW status; exposed as POST /statussen. Unit + real-OpenZaak integration test.
• Event-subscriber — binds NRC hoofdObject, projects a status/create as INGESCHREVEN keyed on the zaak (updates the existing row), without reading OpenZaak (§8.1). Retains the ZGW resource in the log (new column + EF migration) so a rebuild reproduces the status.
• e2e — extended: submit → public INGEDIEND → approve → public INGESCHREVEN.
• Docs — ADR-0011 (the two non-obvious decisions + the walking-skeleton assumption) + demo note.

Key decisions (see ADR-0011)

• ACL discovers the eindstatus (chosen over injecting a statustype URL): no new config/seed plumbing, domain stays ZGW-ignorant.
• Any post-creation status-set ⇒ INGESCHREVEN: in the walking skeleton the only status ever set after creation is the approval, and the subscriber may not read ZGW — documented to tighten when more transitions arrive (S-12+).

Verification

• All .NET unit suites green locally (domain 47, acl 11, event-subscriber 14, bff 16, acceptance 7); Release build + dotnet format clean.
• No new compose config (the eindstatus-discovery approach avoided it).
• The real-OpenZaak integration test (ACL status-set) and the full submit→approve→visible e2e run in CI verify-stack (live NRC→projection + selectielijst egress, not reproducible locally).

closes #75

## What & why S-09b (#75, split from #10) — the **approval flow** that completes the walking skeleton. A behandelaar can now approve a submitted registration; the entry flips from `INGEDIEND` to `INGESCHREVEN` in the public register. Flow: `POST /registrations/{id}/approve` (domain) → ACL sets the zaak eindstatus (ZGW `/statussen`) → OpenZaak → NRC → event-subscriber → projection → openbaar. ## Changes (bottom-up, each red→green TDD) - **Domain** — `RegistrationStatus.Ingeschreven` + `Registration.Approve()` (guards: opened zaak, only from INGEDIEND); `ApproveRegistration` use case (idempotent) + temp `POST /registrations/{id}/approve` endpoint; `IAclClient.ApproveZaakAsync`. - **ACL** — resolves the zaaktype's **eindstatus** from the catalogus (`isEindstatus` / highest volgnummer) and POSTs a ZGW status; exposed as `POST /statussen`. Unit + real-OpenZaak integration test. - **Event-subscriber** — binds NRC `hoofdObject`, projects a `status`/`create` as `INGESCHREVEN` keyed on the zaak (updates the existing row), **without reading OpenZaak** (§8.1). Retains the ZGW `resource` in the log (new column + EF migration) so a rebuild reproduces the status. - **e2e** — extended: submit → public INGEDIEND → approve → public INGESCHREVEN. - **Docs** — ADR-0011 (the two non-obvious decisions + the walking-skeleton assumption) + demo note. ## Key decisions (see ADR-0011) - **ACL discovers the eindstatus** (chosen over injecting a statustype URL): no new config/seed plumbing, domain stays ZGW-ignorant. - **Any post-creation status-set ⇒ INGESCHREVEN**: in the walking skeleton the only status ever set after creation is the approval, and the subscriber may not read ZGW — documented to tighten when more transitions arrive (S-12+). ## Verification - All .NET unit suites green locally (domain 47, acl 11, event-subscriber 14, bff 16, acceptance 7); Release build + `dotnet format` clean. - No new compose config (the eindstatus-discovery approach avoided it). - The real-OpenZaak integration test (ACL status-set) and the full submit→approve→visible e2e run in CI `verify-stack` (live NRC→projection + selectielijst egress, not reproducible locally). closes #75

not added 10 commits 2026-07-13 15:06:25 +00:00

test(domain): approving a registration advances INGEDIEND → INGESCHREVEN (refs #75) ... 551f6e0a0b

Guards: an opened zaak is required and only a submitted registration can be
approved. Fails to compile — Registration.Approve() and RegistrationStatus.
Ingeschreven don't exist yet (red).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(domain): add the Ingeschreven state and Registration.Approve() (refs #75) ... ca9964f79b

Approve() advances a submitted registration with an opened zaak to INGESCHREVEN;
re-approval and approval-before-zaak are rejected as invalid transitions.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(domain): approve use case sets the zaak status via the ACL, idempotently (refs #75) ... 66fe1e5f6f

Red: ApproveRegistration and IAclClient.ApproveZaakAsync don't exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(domain): ApproveRegistration use case + temp /registrations/{id}/approve endpoint (refs #75) ... 3e0d2f9b11

Loads the registration, asks the ACL to set its zaak's final status (new
IAclClient.ApproveZaakAsync → POST /statussen), then advances the aggregate to
INGESCHREVEN. Idempotent: a repeated approval is a no-op. Adds HTTP-adapter tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(acl): approving a zaak sets it to the zaaktype's eindstatus, dated today (refs #75) ... 3e42999c23

Red: AclService.ApproveZaakAsync and IZaakGateway.SetZaakToEindstatusAsync don't exist yet.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(acl): set a zaak to its eindstatus via ZGW + POST /statussen endpoint (refs #75) ... b697b0d865

The gateway resolves the zaaktype's eindstatus from the catalogus (isEindstatus,
falling back to the highest volgnummer) and POSTs a status against the zaak. Exposed
as POST /statussen for the domain's approve use case. Adds an integration test that
sets the eindstatus against a real OpenZaak and verifies the zaak's current status.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(event-subscriber): project INGESCHREVEN from a status-set notification (refs #75) ... b672132ed4

A zaken/status/create notification (hoofdObject = the zaak) updates the zaak's row to
INGESCHREVEN, and a rebuild reproduces it. Red: Notification has no hoofdObject/
IsZaakStatusSet and RegistrationStatus.Ingeschreven doesn't exist.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

feat(event-subscriber): project a status-set as INGESCHREVEN via hoofdObject (refs #75) ... 2cacedc469

Bind the NRC hoofdObject, recognise a zaken/status/create notification, and key the
projection on the zaak (hoofdObject) so the status updates the existing INGEDIEND row
to INGESCHREVEN — without reading OpenZaak (§8.1). Retain the ZGW resource in the log
(new column + migration) so a rebuild reproduces the approved status. Updates the
acceptance fakes for the new IAclClient/IZaakGateway members.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

test(e2e): approve a submitted registration and assert public INGESCHREVEN (refs #75) ... d433bdee0e

Extend the walking-skeleton happy path: after the entry is publicly visible as
INGEDIEND, approve it via the temporary admin endpoint (waiting for the zaak to be
opened first), then poll the openbaar register until it shows INGESCHREVEN —
covering submit → BFF → domain → ACL → NRC → projection → public visibility.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs(architecture): ADR-0011 approval status flow + demo note (refs #75) ... 8badef02af

Records the two non-obvious decisions: the ACL resolves the zaaktype eindstatus
(domain stays ZGW-ignorant), and the event-subscriber projects INGESCHREVEN from
the notification alone (hoofdObject + any status-create), never reading OpenZaak.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added 1 commit 2026-07-14 07:30:05 +00:00

test(acl,domain): cover the approval-flow mutants to hold the ratchet (refs #75) ... 236e7ade9c

The new gateway/use-case code left surviving mutants (empty NoCoverage on the ACL
gateway status-set, plus unasserted error messages, null-guards, and the persist
call). Add stub-handler tests for SetZaakToEindstatusAsync (eindstatus resolution,
POST framing, failure paths) and assert the approve use case's messages, null
handling and SaveAsync. Local Stryker: acl 100%, domain 98.4%, event-subscriber 100%.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added 1 commit 2026-07-14 08:03:18 +00:00

fix(projection): serialise concurrent migrators with a pg advisory lock (refs #75) ... 80d0308de8

verify-up failed: the event-subscriber and projection-api both migrate the shared
projection DB on start, and EF releases its migrations-history lock between individual
migrations — harmless with one migration, but the new AddNotificationResource made a
second, so a migrator re-applied it in the window between the other's two migrations
("column resource already exists"). Hold a session pg_advisory_lock across the whole
MigrateAsync so the sequence runs exactly once; the second migrator then finds nothing
pending.

Verified by starting both images simultaneously against a fresh Postgres: both reach
health, the resource column is created once, and __EFMigrationsHistory has both rows.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not added 1 commit 2026-07-14 08:39:24 +00:00

fix(acl): set a resultaat before the eindstatus so OpenZaak accepts the status (refs #75) ... 9089bd5e88

The status-set integration test hit 400 "resultaat-does-not-exist: Zaak has no
resultaat" — OpenZaak refuses a zaak's eindstatus until the zaak has a resultaat.
Resolve the zaaktype's resultaattype and POST /resultaten before POST /statussen.
Also surface the ZGW response body in the failure exception (EnsureSuccessStatusCode
hid the 400 detail that pinpointed this). Reworked the gateway with shared
GetCatalogusAsync/PostAsync helpers and rewrote the stub-handler tests for the new
4-call flow incl. failure paths. Verified against real OpenZaak (integration test
green) and locally: acl mutation 100%.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

not merged commit 1c185e6686 into main 2026-07-14 09:05:00 +00:00

not referenced this issue from a commit 2026-07-14 09:05:02 +00:00

S-09b: Approval flow — temp admin endpoint + status transition to projection (#77)

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

area:acl

area:bff

area:docs

area:domain

area:event-subscriber

area:infra

area:portal-behandel

area:portal-beheer

area:portal-openbaar

area:portal-self-service

area:projection

area:workflow

type:adr-proposal

type:bug

type:chore

type:slice

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

eho

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eho/register-referentie#77