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