Files

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

3.0 KiB

Raw Blame History

WP-63 — Backend: aanvraag status lifecycle as a published DTO

Status: todo Phase: 11 — Behandelportal

Why

The FE currently infers "in behandeling" from a single boolean, pendingHerregistratie (big-profile.store.ts:53) — explicitly called out in ADR-0002 as "a temporary stand-in for a real, backend-owned status." The full lifecycle (Ingediend → In behandeling → (Meer info gevraagd ⇄) → Goedgekeurd/Afgewezen) needs to become a real backend-published value before either frontend can render it meaningfully — the SSP needs it as a richer read (this WP), the behandelportal needs it as the thing it advances (WP-65).

Read first

ADR-0002 (status lifecycle diagram)
src/app/registratie/application/big-profile.store.ts (the current boolean)
ADR-0001 — BFF-lite decision DTOs

Decisions (pre-made, don't relitigate)

Status lives on the existing Aanvraag/ApplicationSummaryDto aggregate (extend, don't invent a parallel status resource).
The DTO change is additive: the SSP's pendingHerregistratie boolean can be derived from the new status field (or kept as a computed convenience) so this ships with zero required FE behavior change — a pure backend + contract widening.
Only the status value is published here; any transition (advancing it) is a separate write endpoint, not part of this slice (that's WP-65's mutation).

Files

Data/ApplicationStore.cs (status field/enum)
Contracts/Dtos.cs (extend ApplicationSummaryDto/status DTO)
The FE infrastructure/*.adapter.ts + parse* boundary consuming it
big-profile.store.ts (derive the existing boolean from the new field)

Steps

Model the full status enum backend-side (Ingediend, InBehandeling, MeerInfoGevraagd, Goedgekeurd, Afgewezen) on Aanvraag.
Publish it on the existing DTO the SSP already consumes.
Regenerate the typed client (npm run gen:api); update the FE parse* boundary to read the new field.
Point pendingHerregistratie (or its replacement) at the new field so the SSP's existing behavior is unchanged, just backed by a real value.

Acceptance criteria

Backend publishes the full status lifecycle value on the existing aanvraag DTO.
npm run gen:api leaves no drift; SSP's existing "pending" display is unchanged in behavior, now backed by the real status.
dotnet test + npm run ci green.

Verification

cd backend && dotnet test; npm run gen:api (no drift); npm run ci; manual: SSP dashboard still shows the same pending/approved states it does today.

Out of scope

Any endpoint that advances the status (WP-65); the behandelportal consuming it (WP-64).

Risks

If the enum doesn't anticipate a state WP-65 needs (e.g. distinguishing who can transition from what), it gets revised there — acceptable, this slice only needs to cover the states already named in ADR-0002's diagram.

3.0 KiB Raw Blame History