3 Commits

Include renames

Author	SHA1	Message	Date
ehoandClaude Opus 5	194cccfd02	refactor: rename Application → Aanvraag across the wire (Step 1/8) ... The wire said Application, the domain said Aanvraag — one aggregate with two names at every hop. Rename the backend DTOs and the /applications route to /aanvragen, regenerate the typed client, and rename the frontend adapter/store to match. Renamed: ApplicationSummaryDto/DetailDto, CreateApplicationRequest, SubmitApplicationRequest/Response → Aanvraag* equivalents; ApplicationsAdapter/Store → AanvragenAdapter/Store; applications.adapter.ts/applications.store.ts → aanvragen.*. Left untouched: the admin Case/Zaak vocabulary (/admin/cases, AdminCasesStore) — a separate read model, not part of this rename; the internal BigRegister.Domain.Applications namespace and the Applications EF table (renaming those needs a new EF migration, out of scope here). Part of the dashboard-readability refactor (see the approved plan). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-04 14:33:16 +02:00
ehoandClaude Opus 5	487818e67a	fix(privacy): mask the owner BSN on the cross-owner case lists (RB-03) ... Mappers.ToAdminSummaryDto set Owner to the raw BSN. Both consumers are cross-owner lists read by someone who is not the subject — GET /admin/cases and GET /werkvoorraad — while GET /beoordeling/{id}, the detail view of the same data, already masked it. The detail screen showed ******782 and the list one click earlier showed the whole thing. Masked in the mapper rather than at each endpoint, so a third cross-owner list cannot be added that forgets to. MaskTail moves out of Program.cs into Domain/People/Pii.cs: it now has callers in Contracts, Program.cs and (once RB-04 lands) Data, and a second hand-rolled copy is how one of them drifts into leaking. Documented as idempotent, which is what lets /beoordeling/{id} keep its own call — IZaakSource has a second implementation whose Owner is mapped from the OpenZaak zaak identificatie, so that endpoint should not depend on which source answered. No frontend change: all three consumers display the value, and the parse boundaries only require a non-empty string. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-27 10:52:29 +02:00
ehoandClaude Sonnet 5	fe69caee63	feat(behandelportal): WP-64 werkvoorraad (queue) screen ... New GET /werkvoorraad endpoint lists aanvragen still open (Ingediend/InBehandeling), gated by the medewerker capability (CanBeoordelen) rather than the admin role — reuses the existing ApplicationSummaryDto, no new DTO. GET /me now surfaces aanvraag:beoordelen for a behandelaar so the FE can gate with the same AccessStore/capabilityGuard idiom every other page uses. FE: a behandeling domain type deliberately narrower than ssp's full AanvraagStatus union (only the two open tags — illegal states unrepresentable), composed into a werkvoorraad-list organism from existing shared/ui molecules. Replaces WP-61's scaffold placeholder as the app's real landing page. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-02 22:02:35 +02:00