ehoandClaude Sonnet 5
3588057a75
CI / changes (push) Successful in 8s
CI / lint (push) Successful in 12s
CI / frontend (push) Successful in 14s
CI / storybook-a11y (push) Successful in 17s
CI / backend (push) Successful in 1m51s
CI / semgrep (push) Successful in 1m13s
CI / e2e (push) Successful in 2m56s
CI / api-client-drift (push) Successful in 1m41s
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>
70 lines
3.0 KiB
Markdown
70 lines
3.0 KiB
Markdown
# 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](../reference/architecture/0002-user-groups-and-bounded-contexts.md) (status
|
|
lifecycle diagram)
|
|
- `src/app/registratie/application/big-profile.store.ts` (the current boolean)
|
|
- [ADR-0001 — BFF-lite decision DTOs](../reference/architecture/0001-bff-lite-decision-dtos.md)
|
|
|
|
## 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
|
|
|
|
1. Model the full status enum backend-side (`Ingediend`, `InBehandeling`,
|
|
`MeerInfoGevraagd`, `Goedgekeurd`, `Afgewezen`) on `Aanvraag`.
|
|
2. Publish it on the existing DTO the SSP already consumes.
|
|
3. Regenerate the typed client (`npm run gen:api`); update the FE `parse*` boundary to
|
|
read the new field.
|
|
4. 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.
|