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.