Consent-Uebersichtsseite unter /app/show-consent mit Keycloak-User-Filter #221

New issue

Closed

opened 2026-07-04 12:31:39 +00:00 by niboer · 1 comment

niboer commented

2026-07-04 12:31:39 +00:00

Owner

Beschreibung

Neue Admin-Ansicht /app/show-consent fuer User mit edit-person-Permission. Die Seite zeigt eine Tabelle aller Personen mit Keycloak-User-Link und deren DSGVO-Einwilligungsstatus.

Backend

Neuer Endpunkt GET /api/v1/admin/consents
preHandler: requireAuth + requireCompositeRole('edit-person')
Gibt alle Personen mit keycloakId != null zurueck, angereichert mit:
- personId, firstName, lastName, hasKeycloakUser
- email (aus ContactData, unverschluesselt)
- policyVersion (neuster Consent oder null)
- acceptedAt (neuster Consent-Zeitstempel oder null)
OpenAPI-Schema: AdminConsentResponse (analog zu GroupConsentsResponse aber mit firstName, lastName, email)
Tests in src/__tests__/consent.test.ts erweitern

Frontend

Neue Route: frontend/src/routes/app/show-consent/
- +page.server.ts — load-Funktion ruft GET /api/v1/admin/consents auf, gibt Daten an Svelte-Komponente
- +page.svelte — DataTable mit Spalten: Name, E-Mail, Consent-Status (erteilt/nicht erteilt mit policyVersion + Datum)

Sidebar (sidebar.svelte) — neuen Nav-Eintrag einfuegen:

{ href: '/app/show-consent', label: 'Einwilligungen', permission: 'edit-person' }

(vor oder nach Loeschantraege)

i18n:
- frontend/src/lib/i18n/de/consent.json — Keys showConsent.title, showConsent.description, showConsent.granted, showConsent.notGranted, showConsent.email, showConsent.policyVersion, showConsent.acceptedAt
- frontend/src/lib/i18n/en/consent.json — entsprechende EN-Keys

Autorisierungsmatrix

docs/design/03-autorisierungsmatrix.md um den neuen Endpunkt ergaenzen.

Akzeptanzkriterien

Backend-Endpunkt existiert und retourniert nur Personen mit Keycloak-User-Link
Consent-Status (policyVersion, acceptedAt) wird korrekt ermittelt (neuster Consent pro Person)
Frontend-Seite unter /app/show-consent ist erreichbar
Menu-Eintrag ist nur fuer User mit edit-person-Permission sichtbar
Ohne edit-person wird der Menu-Eintrag nicht eingeblendet
Ohne edit-person fuehrt Direktaufruf der Route zu einem 403/Redirect
Backend-Tests decken den neuen Endpunkt ab
i18n-Keys sind in DE- und EN-Dateien vorhanden
Autorisierungsmatrix aktualisiert

## Beschreibung Neue Admin-Ansicht `/app/show-consent` fuer User mit `edit-person`-Permission. Die Seite zeigt eine Tabelle aller Personen mit Keycloak-User-Link und deren DSGVO-Einwilligungsstatus. ## Backend - Neuer Endpunkt `GET /api/v1/admin/consents` - preHandler: `requireAuth + requireCompositeRole('edit-person')` - Gibt alle Personen mit `keycloakId != null` zurueck, angereichert mit: - `personId`, `firstName`, `lastName`, `hasKeycloakUser` - `email` (aus ContactData, unverschluesselt) - `policyVersion` (neuster Consent oder null) - `acceptedAt` (neuster Consent-Zeitstempel oder null) - OpenAPI-Schema: `AdminConsentResponse` (analog zu `GroupConsentsResponse` aber mit `firstName`, `lastName`, `email`) - Tests in `src/__tests__/consent.test.ts` erweitern ## Frontend - Neue Route: `frontend/src/routes/app/show-consent/` - `+page.server.ts` — load-Funktion ruft `GET /api/v1/admin/consents` auf, gibt Daten an Svelte-Komponente - `+page.svelte` — DataTable mit Spalten: Name, E-Mail, Consent-Status (erteilt/nicht erteilt mit policyVersion + Datum) - Sidebar (`sidebar.svelte`) — neuen Nav-Eintrag einfuegen: ```ts { href: '/app/show-consent', label: 'Einwilligungen', permission: 'edit-person' } ``` (vor oder nach `Loeschantraege`) - i18n: - `frontend/src/lib/i18n/de/consent.json` — Keys `showConsent.title`, `showConsent.description`, `showConsent.granted`, `showConsent.notGranted`, `showConsent.email`, `showConsent.policyVersion`, `showConsent.acceptedAt` - `frontend/src/lib/i18n/en/consent.json` — entsprechende EN-Keys ## Autorisierungsmatrix `docs/design/03-autorisierungsmatrix.md` um den neuen Endpunkt ergaenzen. ## Akzeptanzkriterien - [ ] Backend-Endpunkt existiert und retourniert nur Personen mit Keycloak-User-Link - [ ] Consent-Status (policyVersion, acceptedAt) wird korrekt ermittelt (neuster Consent pro Person) - [ ] Frontend-Seite unter `/app/show-consent` ist erreichbar - [ ] Menu-Eintrag ist nur fuer User mit `edit-person`-Permission sichtbar - [ ] Ohne `edit-person` wird der Menu-Eintrag nicht eingeblendet - [ ] Ohne `edit-person` fuehrt Direktaufruf der Route zu einem 403/Redirect - [ ] Backend-Tests decken den neuen Endpunkt ab - [ ] i18n-Keys sind in DE- und EN-Dateien vorhanden - [ ] Autorisierungsmatrix aktualisiert

niboer added this to the MS-FE-6: i18n & Consent milestone

2026-07-04 12:31:39 +00:00

niboer added the

labels

2026-07-04 12:31:39 +00:00

niboer referenced this issue

2026-07-06 16:09:10 +00:00

Personenliste: Haushaltsgruppierung, erweiterte Admin-Ansicht & Person anlegen #254

niboer commented

2026-07-06 16:14:34 +00:00

Author

Owner

Wird durch #254 ersetzt: Die Consent-Uebersicht wird in die erweiterte Personenliste integriert (Admin-Toggle "Erweiterte Ansicht" in /app/persons). Keine separate Seite mehr noetig.

Wird durch #254 ersetzt: Die Consent-Uebersicht wird in die erweiterte Personenliste integriert (Admin-Toggle "Erweiterte Ansicht" in `/app/persons`). Keine separate Seite mehr noetig.

niboer closed this issue

2026-07-06 16:14:38 +00:00

niboer referenced this issue from a commit

2026-07-06 16:16:15 +00:00

feat(frontend+backend): Personenliste mit Haushaltsgruppierung, Admin-Toggle und Person anlegen