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>
73 lines
2.8 KiB
Markdown
73 lines
2.8 KiB
Markdown
# WP-65 — Behandelportal: zaak detail + beoordeling (decision) screen
|
|
|
|
Status: todo
|
|
Phase: 11 — Behandelportal
|
|
|
|
## Why
|
|
|
|
The core case-treatment write path — a medewerker opens one aanvraag's detail (including
|
|
its documents) and records a decision (goedkeuren/afwijzen/meer info opvragen), advancing
|
|
the status lifecycle WP-63 published. This is the first genuinely new _write_ capability
|
|
in the system beyond what the citizen SSP already does to itself.
|
|
|
|
## Read first
|
|
|
|
- `mutation-command` skill
|
|
- `form-machine` skill (the decision action is a state-changing form, same idiom as
|
|
everywhere else in this house)
|
|
- [WP-63](WP-63-aanvraag-status-lifecycle.md) (the status field being advanced)
|
|
|
|
## Decisions (pre-made, don't relitigate)
|
|
|
|
- The decision action is modeled as a `*.machine.ts` (Model/Msg/reduce) + a `submit-*`
|
|
command returning `Result`, per this house's one-idiom-for-forms rule — not a
|
|
hand-rolled mutable field.
|
|
- The mutation endpoint is a new BFF-lite write (per `mutation-command` recipe) that
|
|
transitions the status field from WP-63; it validates the transition is legal
|
|
server-side (e.g. can't approve an already-approved case) — the backend remains the
|
|
authority.
|
|
- Runs against `LocalZaakSource` for this slice; wiring the decision into real OpenZaak is
|
|
explicitly WP-66, not bundled here — keeps this slice's surface to app-level behavior
|
|
only.
|
|
|
|
## Files
|
|
|
|
New mutation endpoint + command in `BigRegister.Api`; `behandeling/ui` detail page +
|
|
`behandeling/application` decision machine in the behandelportal app.
|
|
|
|
## Steps
|
|
|
|
1. Backend: mutation endpoint advancing aanvraag status (goedkeuren/afwijzen/meer-info-
|
|
opvragen), validating the transition.
|
|
2. FE: zaak-detail page (documents + current status) + a decision form machine + submit
|
|
command.
|
|
3. Wire the werkvoorraad list (WP-64) to link into this detail page.
|
|
4. Storybook stories + a11y for the new detail/decision UI.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] A medewerker can view one aanvraag's detail and record a decision that advances its
|
|
status.
|
|
- [ ] Illegal transitions are rejected server-side (tested).
|
|
- [ ] End-to-end smoke: werkvoorraad → detail → decision → status change reflected back
|
|
in the queue.
|
|
- [ ] `npm run ci` (behandelportal app) + `dotnet test` green.
|
|
|
|
## Verification
|
|
|
|
Manual/automated smoke test of the full werkvoorraad → beoordeling → besluit flow against
|
|
`LocalZaakSource`; `npm run ci`; `cd backend && dotnet test`.
|
|
|
|
## Out of scope
|
|
|
|
Writing the decision to real OpenZaak (WP-66).
|
|
|
|
## Risks
|
|
|
|
This is the largest FE slice in Phase 11 — if it feels too big at kickoff, split
|
|
detail-view (read) from decision-recording (write) into two sessions; the WP as scoped
|
|
already keeps them in one slice because a detail view with no decision action isn't
|
|
independently useful for a caseworker.
|
|
|
|
Depends on: WP-64.
|