4 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Sonnet 5	af8a011819	feat(behandelportal): WP-65b beoordeling besluit (decision write) ... Adds POST /beoordeling/{id}/besluit: a Besluit enum (Goedkeuren/Afwijzen/ MeerInfoOpvragen) backed by new Aanvraag.BesluitStatus/BesluitToelichting columns, gated by the same BeoordelingRules.CanDecide the read side's canBesluiten flag already uses (409 on an illegal transition, 400 on a missing required toelichting). Mappers.ToStatusDto gains the "a recorded decision wins" branch. FE: besluit.machine.ts + besluit-form organism (same form idiom as change-request-form), wired into the beoordeling page behind the server's canBesluiten flag. Completes WP-65 (65a + 65b) — verified end-to-end against a running backend (werkvoorraad -> beoordeling -> besluit -> status reflected back). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:46:20 +02:00
ehoandClaude Sonnet 5	4133b30e5d	feat(behandelportal): WP-65a beoordeling detail (read) + fix unreachable medewerker login ... New GET /beoordeling/{id} shows one aanvraag's status, linked documents, and a canBesluiten decision flag, gated by the same CanBeoordelen capability as the werkvoorraad list. Reads through IZaakSource.ListCases rather than a new seam method (WP-66 needs one anyway for the real write); owner BSN is masked. Fixes a real gap found while wiring this up: the behandelportal's login was still WP-61's copied citizen/BSN DigiD flow, so nothing ever sent X-Medewerker and the werkvoorraad screen (WP-64) always denied in a real browser. A dev-only medewerkerInterceptor (mirrors the existing ?role= stand-in as ?rollen=) fixes that. WP-65's own Risks note authorized splitting read from write across sessions given its size; this is the read half. The decision-recording mutation is next (65b). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-03 09:01:09 +02:00
ehoandClaude Sonnet 5	3588057a75	feat(openzaak): real secrets + TLS for the production OpenZaak harness (WP-55) ... 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
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