MABEA/arbeitskacheln/12_personnel.md

# Epic 12 — Personnel

Details zu PERS-001 … PERS-007 (vollständig).

---

## PERS-001 — Person (fachlich)

- **Ziel:** Fachliches Konzept einer Person, getrennt vom technischen Login.
- **Beschreibung:** Person-Entität (Name, Geburtsdatum optional, Kontaktdaten) — kann
  existieren OHNE Systemzugang (z.B. Jugendgruppe, externe Kontaktperson).
- **Benutzerwert:** Nicht jede Person im System braucht einen Login (Kinder/Jugendliche,
  externe Helfer ohne digitale Nutzung).
- **Abhängigkeiten:** FOUND-002
- **Datenmodell:** `person` (id, name, geburtsdatum, kontakt)
- **Backend:** CRUD
- **Frontend:** Verwaltung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein (Person ist keine physische Ressource im
  engeren Sinn — ein optionaler QR-Ausweis wäre ein Erweiterungspunkt, kein Kern)
- **Akte:** eigene Personen-Akte möglich (eigenes Konzept, nicht Ressourcen-Akte)
- **Rechte:** Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Person ohne Benutzerkonto anlegbar.
- **Tests:** CRUD-Test, Test „Person ohne Benutzer funktioniert".
- **DoD:** **HIGH RISK** (siehe Decision Required #4 in `00_index.md`) — größter Umbau
  des gesamten Personal-Bereichs, da MABEA Person=Benutzer verschmolzen hat. Vor
  Umsetzung: echten Bedarf klären (gibt es in der Praxis tatsächlich Personen ohne
  Login-Bedarf, die trotzdem im System geführt werden müssen?).

## PERS-002 — Benutzer (technisch, verknüpft)

- **Ziel:** Systemzugang, verknüpft mit einer Person.
- **Beschreibung:** `Benutzer` (login, passwort_hash) referenziert optional eine Person
  (1:1 oder 1:0..1).
- **Benutzerwert:** Systemzugang bleibt wie gehabt, aber fachlich sauber von der
  Personen-Stammdatenverwaltung getrennt.
- **Abhängigkeiten:** PERS-001, FOUND-003
- **Datenmodell:** `benutzer.person_id` (FK, optional während Übergang)
- **Backend:** Migration bestehender Benutzer zu Person-Datensätzen
- **Frontend:** Benutzeranlage erzeugt/verknüpft Person
- **Mobile:** kein Unterschied
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** nein direkt
- **Rechte:** bestehende Rechte-Logik unverändert
- **Audit:** Verknüpfung geloggt
- **Akzeptanzkriterien:** bestehende Benutzer funktionieren nach Migration unverändert.
- **Tests:** Migrationstest (keine Datenverluste), Regressionstest bestehender
  Auth-Flows.
- **DoD:** **DECISION REQUIRED** — das ist der eigentliche Bruch. Lohnt sich das, wenn
  aktuell niemand Personen ohne Login braucht? Empfehlung: zurückstellen bis konkreter
  Bedarf auftritt (z.B. Jugendgruppen-Verwaltung), dann als eigenes fokussiertes Vorhaben
  angehen, nicht „nebenbei" im Rahmen einer anderen Kachel.

## PERS-003 — Einheiten/Organisationsstruktur

- **Ziel:** Hierarchische Gliederung von Personen in Züge/Gruppen.
- **Beschreibung:** Einheit mit optionaler übergeordneter Einheit, Person/Benutzer gehört
  zu einer Einheit.
- **Benutzerwert:** Organisationsstruktur abbildbar (Zug → Gruppe → Trupp).
- **Abhängigkeiten:** PERS-001 (oder direkt Benutzer, falls PERS-001 zurückgestellt)
- **Datenmodell:** `einheit` (id, name, uebergeordnete_einheit_id, standort_id)
- **Backend:** CRUD
- **Frontend:** Verwaltung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Verantwortlichkeitsbereich (FILE-004) referenziert Einheit
- **Rechte:** Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** mehrstufige Hierarchie anlegen (Zug→Gruppe).
- **Tests:** Baum-Test.
- **DoD:** deckt sich mit MABEA (`Einheit`-Modell bereits umgesetzt, self-referenzierend)
  — allerdings bisher nur eine Ebene in der Praxis genutzt, mehrstufige Hierarchie ist
  technisch möglich aber ungetestet im echten Einsatz.

## PERS-004 — Funktionen/Rollen im Einsatzkontext

- **Ziel:** Fachliche Funktion einer Person innerhalb einer Einheit (Zugführer, Melder,
  Fahrer, ...) — unterscheidet sich von System-Rollen (Rechte).
- **Beschreibung:** Funktion als Stammdatum, Zuordnung Person↔Einheit↔Funktion.
- **Benutzerwert:** „Wer ist der Zugführer von Zug 3" beantwortbar, unabhängig von
  Systemrechten.
- **Abhängigkeiten:** PERS-003
- **Datenmodell:** `funktion` (id, name), `einheit_mitgliedschaft` (person_id,
  einheit_id, funktion_id)
- **Backend:** CRUD
- **Frontend:** Zuordnung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Verantwortlichkeitsbereich
- **Rechte:** Administrator/Zugführer
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Person mit Funktion in Einheit zuordnen.
- **Tests:** CRUD-Test.
- **DoD:** komplett neu in MABEA — Einheit-Zuordnung existiert (`Benutzer.einheit_id`),
  aber keine fachliche Funktion/Rolle INNERHALB der Einheit (nur System-Rollen wie
  „Materialverantwortlicher" existieren — das ist etwas anderes als „Zugführer von
  Zug 3").

## PERS-005 — Qualifikationen/Lehrgänge

- **Ziel:** Nachgewiesene Qualifikationen einer Person.
- **Beschreibung:** Qualifikationstyp-Katalog + Zuordnung mit Erwerbsdatum/Gültigkeit.
- **Benutzerwert:** Nachweis von Ausbildungsstand.
- **Abhängigkeiten:** PERS-001
- **Datenmodell:** `qualifikationstyp`, `benutzer_qualifikation`
- **Backend:** CRUD
- **Frontend:** Verwaltung
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** eigener Bereich (Personen-Akte)
- **Rechte:** Administrator
- **Audit:** Änderung geloggt
- **Akzeptanzkriterien:** Qualifikation mit Gültigkeit erfassen.
- **Tests:** CRUD-Test.
- **DoD:** deckt sich 1:1 mit MABEA (`Qualifikationstyp`/`BenutzerQualifikation` bereits
  umgesetzt, inkl. Ablauf-Dashboard-Kachel).

## PERS-006 — Führerscheine/Berechtigungen mit Gültigkeit

- **Ziel:** Spezialfall von PERS-005 — Fahrerlaubnis, die bestimmt, wer welches Fahrzeug
  fahren darf.
- **Beschreibung:** Führerschein als Qualifikationskategorie, Verknüpfung zu
  AssetType-Anforderung.
- **Benutzerwert:** „Wer darf dieses Fahrzeug fahren" automatisch beantwortbar.
- **Abhängigkeiten:** PERS-005, ASSET-002
- **Datenmodell:** `objekttyp_qualifikationsanforderung` (M:N)
- **Backend:** Berechtigungsprüfungs-Endpunkt
- **Frontend:** Anzeige „fehlende Qualifikation"
- **Mobile:** Anzeige vor Fahrtantritt
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** Fahrzeug-Akte zeigt erforderliche Qualifikation
- **Rechte:** wie Lese-Recht
- **Audit:** nein zusätzlich
- **Akzeptanzkriterien:** Prüfung liefert korrekt berechtigt/nicht berechtigt + fehlende
  Typen.
- **Tests:** Berechtigungstest (mit/ohne/abgelaufene Qualifikation).
- **DoD:** deckt sich 1:1 mit MABEA — bereits umgesetzt und in dieser Session live gegen
  den Produktivserver getestet (`GET /objekte/{id}/berechtigung/{benutzer_id}`).

## PERS-007 — Qualifikationsablauf-Warnungen

- **Ziel:** Frühwarnung vor ablaufenden Qualifikationen.
- **Beschreibung:** Dashboard-Kachel analog Prüftermine/Ablaufdaten.
- **Benutzerwert:** Rechtzeitig Nachschulung planen, bevor jemand mit abgelaufener
  Qualifikation eingeteilt wird.
- **Abhängigkeiten:** PERS-006
- **Datenmodell:** keins neu
- **Backend:** Abfrage bevorstehender Abläufe
- **Frontend:** Dashboard-Kachel
- **Mobile:** Anzeige
- **QR-Code/Seriennummer/Inventarnummer:** nein
- **Akte:** nein (übergreifende Sicht)
- **Rechte:** Verantwortliche
- **Audit:** nein
- **Akzeptanzkriterien:** korrekte Sortierung, 60 Tage Standard-Vorlauf.
- **Tests:** Schwellenwerttest.
- **DoD:** deckt sich 1:1 mit MABEA
  (`dashboard.bevorstehende_qualifikationsablaeufe()`, bereits umgesetzt).

---

**MABEA-Ist-Stand-Abgleich:** PERS-003, 005, 006, 007 sind vollständig in MABEA
umgesetzt und größtenteils sogar schon live getestet. **PERS-001/002 (Person↔Benutzer-
Trennung) bleiben der einzige echte offene Architekturentscheid im gesamten Backlog** —
bewusst nicht einfach umgesetzt, sondern als Decision Required markiert, da der Nutzen
(Personen ohne Login) bisher nicht als konkreter Bedarf geäußert wurde. **PERS-004
(fachliche Funktion innerhalb einer Einheit, z.B. „Zugführer") fehlt komplett** — leicht
zu verwechseln mit den bestehenden System-Rollen, ist aber ein eigenständiges Konzept.