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

New issue

Closed

opened 2026-07-06 16:09:10 +00:00 by niboer · 0 comments

niboer commented

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

Owner

Beschreibung

Die Personenliste (/app/persons) wird um Haushaltsgruppierung, eine erweiterte Admin-Ansicht und die Person-Neuanlage erweitert.

Phase 1 — Backend: `include=consent`

Analog zu include=emailaddress (PR #256 / Commit 6804774):

parsePersonInclude: 'consent' ins valid-Set aufnehmen
PERSON_CONSENT_INCLUDE: consentsGiven: { take: 1, orderBy: { acceptedAt: 'desc' } }
mapPersonConsent() fuegt consentGranted: boolean zum Response hinzu
PersonWithGroup in openapi.yaml: consentGranted: boolean ergaenzen
Unit-Tests (mit/ohne consent, kombiniert mit group+emailaddress)
Orval-Typen regenerieren

Dateien: backend/src/routes/persons.ts, backend/openapi.yaml, backend/src/__tests__/persons.test.ts, frontend/src/lib/api/generated.ts

Phase 2 — Frontend: Personenliste umbauen

Gruppierung nach Haushalt

Client-seitig via $derived.by – exakt wie die Gaesteliste im Event-Detail (householdGroups-Pattern). API-Call mit ?include=group,emailaddress,consent&archived=....

Spalten je nach Rolle/Ansicht

Kontext	Spalten
Non-Admin (kein edit-person)	Name, Status
Admin (edit-person)	Name, Status, Benutzer
Admin + Erweiterte Ansicht	Name, Status, E-Mail, Zustimmung, Benutzer, Aktionen

"Erweiterte Ansicht" Toggle: Nur fuer edit-person sichtbar, nicht persistent
"Person anlegen" Button: Nur edit-person, oeffnet PersonEditModal im create-Modus
Sortierung: 4 Richtungen + unsorted = 5 Klicks (Standard DataTable-Verhalten)

PersonEditModal erweitern

Neues Prop mode: 'edit' | 'create'
create-Modus: leere Felder, Household-Dropdown mit allen Gruppen (/api/v1/groups)
edit-Modus: bestehendes Verhalten, Dropdown inaktiv/ausgegraut
Neue FormAction ?/create in +page.server.ts
Nach Anlage: bei ausgewaehlter Gruppe → POST /api/v1/groups/{id}/join-request (Beitrittsanfrage)
Personen ohne Haushalt werden ohne Gruppe angelegt

Dateien: frontend/src/routes/app/persons/+page.svelte, frontend/src/routes/app/persons/+page.server.ts, frontend/src/lib/components/person-edit-modal.svelte, frontend/src/lib/config/person-table.ts, frontend/src/lib/i18n/de/persons.json

Phase 3 — E2E-Tests

Komplette Neuimplementierung von e2e/specs/test-2-independent/persons.spec.ts:

Test 1 — Thomas Koenig (app-user, kein edit-person):

Kein "Erweiterte Ansicht" Toggle, kein "Person anlegen" Button
Tabs Alle, Aktiv, Archiviert sichtbar
2 Spalten: Name, Status
Tab Aktiv ausgewaehlt
3 Gruppen: Einzeln (7), Deviluke (3), Mustermann-Musterfrau (>1)
Sortierung in Einzeln: 5 Modi, Reihenfolge kontrollieren
Wechsel zu Archiviert: 2 Gruppen (Einzeln 1, Alt-Haushalt 2)
Wechsel zu Alle: 4 Gruppen

Test 2 — Max Mustermann (app-admin, edit-person):

"Erweiterte Ansicht" Toggle sichtbar
"Person anlegen" Button sichtbar
3 Spalten default: Name, Status, Benutzer
Erweiterte Ansicht aktivieren: 6 Spalten
Zeilen-Inhalte validieren (Max: max@example.com, Erteilt; Rito: rito.deviluke@example.com, nicht Erteilt, kein Benutzer)
Rito bearbeiten: E-Mail aendern → Speichern → Spalte aktualisiert
Rito einladen: Erfolgsmeldung, Benutzer-Spalte aktualisiert
Francois archivieren: verschwindet aus Aktiv, taucht in Archiviert auf

Abhaengigkeiten

PR #256 (include=emailaddress) muss gemergt sein (Branch issue-254-2 bereits rebased)
Seed-Daten enthalten alle benoetigten Personen, Gruppen und Kontaktdaten

Issue-Referenzen

Vorbereitung durch #256 (include=emailaddress)
Schliesst #221 (Consent-Uebersicht wird in Personenliste integriert)

Checkliste

use:testid an neuen <button>, <a>, <form>-Elementen gesetzt
Korrespondierender E2E-Test aktualisiert

### Beschreibung Die Personenliste (`/app/persons`) wird um Haushaltsgruppierung, eine erweiterte Admin-Ansicht und die Person-Neuanlage erweitert. --- ### Phase 1 — Backend: `include=consent` Analog zu `include=emailaddress` (PR #256 / Commit 6804774): - `parsePersonInclude`: `'consent'` ins valid-Set aufnehmen - `PERSON_CONSENT_INCLUDE`: `consentsGiven: { take: 1, orderBy: { acceptedAt: 'desc' } }` - `mapPersonConsent()` fuegt `consentGranted: boolean` zum Response hinzu - `PersonWithGroup` in `openapi.yaml`: `consentGranted: boolean` ergaenzen - Unit-Tests (mit/ohne consent, kombiniert mit group+emailaddress) - Orval-Typen regenerieren **Dateien:** `backend/src/routes/persons.ts`, `backend/openapi.yaml`, `backend/src/__tests__/persons.test.ts`, `frontend/src/lib/api/generated.ts` --- ### Phase 2 — Frontend: Personenliste umbauen #### Gruppierung nach Haushalt Client-seitig via `$derived.by` – exakt wie die Gaesteliste im Event-Detail (`householdGroups`-Pattern). API-Call mit `?include=group,emailaddress,consent&archived=...`. #### Spalten je nach Rolle/Ansicht | Kontext | Spalten | |---|---| | Non-Admin (kein edit-person) | Name, Status | | Admin (edit-person) | Name, Status, Benutzer | | Admin + Erweiterte Ansicht | Name, Status, E-Mail, Zustimmung, Benutzer, Aktionen | - **"Erweiterte Ansicht" Toggle:** Nur fuer edit-person sichtbar, nicht persistent - **"Person anlegen" Button:** Nur edit-person, oeffnet PersonEditModal im `create`-Modus - **Sortierung:** 4 Richtungen + unsorted = 5 Klicks (Standard DataTable-Verhalten) #### PersonEditModal erweitern - Neues Prop `mode: 'edit' | 'create'` - `create`-Modus: leere Felder, Household-Dropdown mit allen Gruppen (`/api/v1/groups`) - `edit`-Modus: bestehendes Verhalten, Dropdown inaktiv/ausgegraut - Neue FormAction `?/create` in `+page.server.ts` - Nach Anlage: bei ausgewaehlter Gruppe → `POST /api/v1/groups/{id}/join-request` (Beitrittsanfrage) - Personen ohne Haushalt werden ohne Gruppe angelegt **Dateien:** `frontend/src/routes/app/persons/+page.svelte`, `frontend/src/routes/app/persons/+page.server.ts`, `frontend/src/lib/components/person-edit-modal.svelte`, `frontend/src/lib/config/person-table.ts`, `frontend/src/lib/i18n/de/persons.json` --- ### Phase 3 — E2E-Tests Komplette Neuimplementierung von `e2e/specs/test-2-independent/persons.spec.ts`: **Test 1 — Thomas Koenig (app-user, kein edit-person):** - Kein "Erweiterte Ansicht" Toggle, kein "Person anlegen" Button - Tabs Alle, Aktiv, Archiviert sichtbar - 2 Spalten: Name, Status - Tab Aktiv ausgewaehlt - 3 Gruppen: Einzeln (7), Deviluke (3), Mustermann-Musterfrau (>1) - Sortierung in Einzeln: 5 Modi, Reihenfolge kontrollieren - Wechsel zu Archiviert: 2 Gruppen (Einzeln 1, Alt-Haushalt 2) - Wechsel zu Alle: 4 Gruppen **Test 2 — Max Mustermann (app-admin, edit-person):** - "Erweiterte Ansicht" Toggle sichtbar - "Person anlegen" Button sichtbar - 3 Spalten default: Name, Status, Benutzer - Erweiterte Ansicht aktivieren: 6 Spalten - Zeilen-Inhalte validieren (Max: max@example.com, Erteilt; Rito: rito.deviluke@example.com, nicht Erteilt, kein Benutzer) - Rito bearbeiten: E-Mail aendern → Speichern → Spalte aktualisiert - Rito einladen: Erfolgsmeldung, Benutzer-Spalte aktualisiert - Francois archivieren: verschwindet aus Aktiv, taucht in Archiviert auf --- ### Abhaengigkeiten - PR #256 (`include=emailaddress`) muss gemergt sein (Branch `issue-254-2` bereits rebased) - Seed-Daten enthalten alle benoetigten Personen, Gruppen und Kontaktdaten ### Issue-Referenzen - Vorbereitung durch #256 (include=emailaddress) - Schliesst #221 (Consent-Uebersicht wird in Personenliste integriert) ### Checkliste - [ ] `use:testid` an neuen `<button>`, `<a>`, `<form>`-Elementen gesetzt - [ ] Korrespondierender E2E-Test aktualisiert

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

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

niboer added the

labels

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

niboer referenced this issue

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

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