florian.wildeandClaude Opus 5.5
b5b43f41f6
Personen lassen sich anlegen, bearbeiten und archivieren; ihr Detail zeigt ihre Schluessel. Unter "Meine Schluessel" hinterlegt jede Rolle eigene Public Keys (Freigabe Frage 4), wirksam erst nach Zuweisung durch einen Operator oder Admin. Warum so: - Die eigene Person entsteht beim ersten Aufruf oder wird verknuepft: per benutzerId, sonst per E-Mail - aber nur, wenn der OIDC-Anbieter die Adresse bestaetigt hat. Dafuer merkt sich Benutzer jetzt emailBestaetigt (Migration); sonst koennte jemand mit selbst gewaehlter Adresse die Keys einer fremden Person sehen. - Die Self-Service-Services nehmen nur den angemeldeten Benutzer und leiten die Person selbst ab; fremde Schluessel-IDs gelten als nicht vorhanden. - Entfernen nur fuer eigene, selbst hinterlegte Keys ohne Verwendung, bedingt geloescht, damit eine gleichzeitige Zuweisung nicht per Cascade verschwindet. - Archivieren statt Loeschen: wer bis wann welchen Key hatte, bleibt nachvollziehbar. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
# #013 Personen und Self-Service
|
||
**Status:** erledigt
|
||
**Meilenstein:** v0.2.0
|
||
**Labels:** backend, ui
|
||
**Geschätzt:** 2 h **Tatsächlich:** 0 h 10 min
|
||
|
||
## Ziel
|
||
Personen verwalten; jeder angemeldete Benutzer kann eigene Public Keys hinterlegen, wirksam erst nach Zuweisung.
|
||
|
||
## Aufgaben
|
||
- [x] Personenliste/-detail
|
||
- [x] Seite „Meine Schlüssel“
|
||
|
||
## Akzeptanzkriterien
|
||
- [x] Leser kann nur eigene Keys hinterlegen, nicht zuweisen
|
||
|
||
## Abhängigkeiten
|
||
#012
|
||
|
||
## Notizen / Entscheidungen
|
||
- **Personen pflegt, wer Schlüssel verwaltet** (Recht `schluesselVerwalten`, Admin und Operator) –
|
||
ein eigenes Recht wäre nur ein Alias. Lesen dürfen alle Rollen.
|
||
- **Archivieren statt Löschen:** die Schlüssel bleiben der Person zugeordnet (wer hatte bis wann
|
||
welchen Key?), die Kontoverknüpfung entfällt, damit der Self-Service nicht bei einer
|
||
archivierten Person landet. Die Notiz steht nicht im Protokoll, nur dass sie sich änderte.
|
||
- **Self-Service `/meine-schluessel`** (Recht `eigeneSchluesselHinterlegen`, alle Rollen,
|
||
Navigation „Meine Schlüssel“): beim ersten Aufruf wird die eigene Person angelegt oder
|
||
verknüpft – per `benutzerId`, sonst per E-Mail, aber **nur bei vom Anbieter bestätigter
|
||
Adresse** und genau einer freien, nicht archivierten Person. Dafür neue Spalte
|
||
`Benutzer.emailBestaetigt` (Migration `20261012103000_benutzer_email_bestaetigt`), gesetzt bei
|
||
jeder OIDC-Anmeldung. Ohne sie könnte jemand mit selbst gewählter Adresse die Keys einer fremden
|
||
Person sehen.
|
||
- Hinterlegte Keys: Kategorie `PERSON`, `selbstHinterlegt = true`, Protokoll
|
||
`schluessel.selbst_hinterlegt`. Hinweis in der Oberfläche: „Wirksam erst, wenn ein Operator
|
||
oder Admin den Schlüssel einem Host zuweist.“
|
||
- **Entfernen** nur eigene, selbst hinterlegte Keys ohne jede Verwendung (auch keine entfernte –
|
||
der Verlauf am Key bleibt). Das Löschen ist bedingt (`deleteMany` mit „keine Verwendungen“),
|
||
damit eine gleichzeitige Zuweisung nicht per Cascade verschwindet. Fremde IDs gelten als „nicht
|
||
vorhanden“. Tests: `tests/personen.test.ts`.
|
||
- Die Services nehmen den angemeldeten Benutzer entgegen und leiten die Person selbst ab; die
|
||
Actions reichen keine `personId` von außen durch (struktureller Test).
|