docker-compose.openzaak.prod.yml layers real SECRET_KEY/DB password/site
domain/allowed-hosts (all required, fail-fast via ${VAR:?...}) on top of the
WP-54 dev harness, switches Postgres off trust auth, and sets IS_HTTPS for a
front-facing reverse-proxy TLS setup. The ZGW client secret lives inside a
file setup_configuration reads rather than a compose env var, so it's
templated (data.prod.yaml.template, no secret) and rendered host-side via
render-prod-secrets.sh into a gitignored data.prod.yaml, mounted over the
container's dev data.yaml. ZgwOptions.cs already binds from IConfiguration,
so the BFF side needed no code change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-30 12:27:21 +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