Files

T

florian.wildeandClaude Opus 5.5 b5b43f41f6 feat(personen): Personen und Self-Service Meine Schluessel (#013 )

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>

2026-10-12 10:38:55 +02:00

2.2 KiB

Raw Blame History

#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

Personenliste/-detail
Seite „Meine Schlüssel“

Akzeptanzkriterien

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).

2.2 KiB Raw Blame History Unescape Escape