diff --git a/arbeitskacheln/00_index.md b/arbeitskacheln/00_index.md index 33a8979..0b66536 100644 --- a/arbeitskacheln/00_index.md +++ b/arbeitskacheln/00_index.md @@ -217,6 +217,7 @@ eigenes Modul (MAINT-\*, MABEA hat nur Prüfung, keine Wartung)**. | `09_inspections.md` | INSP-001 … INSP-006 (vollständig) | | `10_maintenance.md` | MAINT-001 … MAINT-006 (vollständig) | | `11_defects.md` | DEFECT-001 … DEFECT-005 (vollständig) | +| `12_personnel.md` | PERS-001 … PERS-007 (vollständig) | -Restliche Kacheln (PERS, READY, DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, -Details folgen nach Freigabe. +Restliche Kacheln (READY, DOC, MOBILE, OPS): nur Zeile in der Tabelle oben, Details folgen +nach Freigabe. diff --git a/arbeitskacheln/12_personnel.md b/arbeitskacheln/12_personnel.md new file mode 100644 index 0000000..333005e --- /dev/null +++ b/arbeitskacheln/12_personnel.md @@ -0,0 +1,169 @@ +# 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.