MABEA/arbeitskacheln/17_zustaendigkeit.md

Epic 17 — Zuständigkeit

Details zu ZUST-001 … ZUST-003. ZUST-001/002 vollständig, ZUST-003 ergänzt am 2026-09-09 aus Open-Source-Vergleich, noch offen/ungeplant. Übernommen aus arbeitskarten/01_rollen_zuordnung.md und arbeitskarten/04_organisationsstruktur.md (Karte 01+04) — beide Karten hatten kein Gegenstück im ursprünglichen 16-Epic-Backlog (siehe 00_index.md, DECISION REQUIRED Punkt 5 war die Vorgängerlücke, diese hier ist die zweite gefundene Lücke).

---

ZUST-001 — Objekt/Standort ↔ Verantwortlicher (Zuständigkeit)

• Ziel: Administrator kann Verantwortliche flexibel Standorten und/oder Objekten zuordnen, ohne starre zentrale/dezentrale Struktur vorzugeben.
• Beschreibung: Zuständigkeit ist n:m (Verantwortlicher(e) ↔ Standort und/oder Objekt), kein Hardcoding "eine Wache = ein Verantwortlicher". Ein Objekt kann mehrere Verantwortliche gleichzeitig haben. Zuständigkeit vererbt sich vom Standort automatisch auf alle Objekte an diesem Standort; eine zusätzliche objektspezifische Zuordnung ist eine feinere Ergänzung obendrauf, kein Ersatz — Auswertelogik: ein Benutzer ist für ein Objekt zuständig, wenn ENTWEDER eine Standort-Zeile für dessen Standort ODER eine Objekt-Zeile für das Objekt selbst existiert (Vereinigung, keine Überschreibung).
• Benutzerwert: Verantwortlichkeiten lassen sich so einteilen, wie die Organisation tatsächlich arbeitet, nicht wie ein starres Schema es vorgibt.
• Abhängigkeiten: FOUND-002, ASSET-003
• Datenmodell: zustaendigkeit (benutzer_id, standort_id NULLABLE, objekt_id NULLABLE)
• Backend: CRUD, Auswertelogik (Vereinigung Standort-/Objekt-Zuordnung)
• Frontend: Verwaltungs-UI (Liste + Suche)
• Mobile: keine eigene UI, wirkt sich auf Sichtbarkeit/Priorisierung aus
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Verantwortlichkeitsbereich (FILE-004)
• Rechte: Administrator verwaltet
• Audit: Änderung geloggt
• Akzeptanzkriterien: Zuordnung auf Standort-Ebene wirkt auf alle zugehörigen Objekte, zusätzliche Objekt-Zuordnung erweitert statt überschreibt.
• Tests: Vererbungslogik-Test (Standort-Zuordnung + separate Objekt-Zuordnung gleichzeitig).
• DoD: deckt sich 1:1 mit MABEA (Zustaendigkeit-Tabelle, admin-UI mit Suche bereits produktiv).

ZUST-002 — Objekt ↔ Benutzer/Gruppe (Kontrollzuweisung, freiwillig)

• Ziel: Verantwortliche können Objekte gezielt einer Einzelperson oder Gruppe zuweisen, ohne dass dies eine Pflichtkontrolle erzwingt.
• Beschreibung: Grundsätzlich darf jeder Mitarbeiter jedes Objekt kontrollieren (keine feste Pflichtzuordnung). Zuweisung ist reine Empfehlung/Sichtbarkeit/Priorisierung, kein Zugriffsschutz — Schutz vor Doppelarbeit übernimmt die Objekt-Sperre nach Scan/ Kontrollstart, nicht die Zuweisung.
• Benutzerwert: Klare Orientierung, wer für was zuständig ist, ohne andere auszuschließen (wichtig bei Vertretung/Ausfall).
• Abhängigkeiten: ZUST-001, PERS-003 (Gruppe)
• Datenmodell: kontrollverantwortung (objekt_id, benutzer_id NULLABLE, gruppe NULLABLE)
• Backend: CRUD
• Frontend: Verwaltungs-UI
• Mobile: zugewiesene Objekte ggf. hervorgehoben/priorisiert in der Liste
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: Verantwortlichkeitsbereich
• Rechte: Administrator/Verantwortliche verwalten, Mitarbeiter sieht alle Objekte
• Audit: Änderung geloggt
• Akzeptanzkriterien: Zuweisung sichtbar/priorisiert, verhindert aber nicht, dass ein anderer Mitarbeiter das Objekt trotzdem kontrolliert.
• Tests: Zuweisungs-CRUD-Test.
• DoD: deckt sich 1:1 mit MABEA (Kontrollverantwortung-Tabelle, admin-UI bereits produktiv).

ZUST-003 — Standort-Scoping für granulare Berechtigungen (P2, neu, geklärt 2026-09-09)

• Ziel: Custom-Rollen-Berechtigungen (Berechtigung/Rolle/RolleBerechtigung, Roadmap Phase 6) optional auf einen Standort/Depot einschränken können, statt immer global zu gelten.
• Bedarf: bestätigt (2026-09-09) — echte Anforderung, kein rein hypothetisches Feature.
• Beschreibung: Aktuell gilt jede über eine Custom-Rolle vergebene Berechtigung systemweit — ein Nutzer mit „material.erstellen" darf das an JEDEM Standort, nicht nur an dem, für den er zuständig ist. Erweiterung: optionales standort_id an der Benutzer-Rollen-Zuordnung, NULL = weiterhin global (Rückwärtskompatibilität).
• Benutzerwert: Ein Materialwart kann Rechte für seinen Standort bekommen, ohne automatisch auch an allen anderen Standorten schreiben zu dürfen — relevant, sobald mehrere Standorte/Depots von unterschiedlichen Personen verantwortet werden.
• Abhängigkeiten: ZUST-001 (bestehendes Standort↔Verantwortlicher-Konzept), das granulare Rechtesystem (app/models/permission.py)
• Datenmodell (entschieden 2026-09-09): 1:1, einfache Spalte statt Zwischentabelle — benutzer_rolle_zuordnung.standort_id (FK, nullable), NULL = global. Begründung: Personen wechseln typischerweise komplett den Standort (dann wird der Wert einfach aktualisiert, kein Neuanlegen/Löschen nötig) statt dauerhaft mehreren Standorten gleichzeitig zugeordnet zu sein. Braucht eine Person doch mehrere Standorte gleichzeitig: einfach eine zweite Rollen-Zuweisung mit anderem standort_id anlegen (Custom-Rollen sind bereits mehrfach zuweisbar) — kein n:m-Konstrukt nötig, deutlich einfachere Rechteprüfungs-Logik.
• Backend: Rechte-Check-Funktion (require_roles_or_permission o.ä.) um Standort-Filter erweitern — prüft nicht nur „hat Berechtigung X", sondern „hat Berechtigung X für Standort Y (oder global)"
• Frontend: RolleSection.tsx — Standort-Auswahl bei der Benutzer-Zuordnung ergänzen (optional, Default weiterhin global)
• Mobile: kein Unterschied, wirkt sich nur auf Backend-Autorisierung aus
• QR-Code/Seriennummer/Inventarnummer: nein
• Akte: nein direkt
• Rechte: Verwaltung: Administrator
• Audit: Änderung der Standort-Zuordnung geloggt
• Akzeptanzkriterien: Nutzer mit standortgebundenem Recht kann an zugewiesenem Standort handeln, an anderem Standort wird derselbe Endpunkt korrekt abgelehnt; bestehende globale Zuordnungen (standort_id IS NULL) funktionieren unverändert.
• Tests: Positivtest (Standort passt), Negativtest (falscher Standort abgelehnt), Regressionstest (bestehende globale Rechte weiterhin uneingeschränkt).
• DoD: offen — beide Design-Entscheidungen geklärt (2026-09-09), bereit für Implementierung. Referenz (Open-Source-Vergleich 2026-09-09): keines der verglichenen Projekte (InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS) hat ein sauber dokumentiertes Standort-/Objekt-Ebene-Rechtesystem — Snipe-IT nur grobes Company-Scoping, Shelf.nu nur personenbezogene Sichtbarkeits-Toggles. Wäre bei Umsetzung eine echte Differenzierung ggü. allen verglichenen Projekten, kein Nachbau.

---

MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-09): ZUST-001/002 sind bereits vollständig umgesetzt und produktiv (Zustaendigkeit + Kontrollverantwortung, jeweils mit Admin-UI). Diese Epic-Datei existierte bislang nicht — reine Nachdokumentation von bereits gebauter Funktion, die im ursprünglichen 16-Epic-Backlog übersehen wurde. ZUST-003 (Standort-Scoping für Berechtigungen) neu ergänzt am 2026-09-09 aus Open-Source-Vergleich, offen/ungeplant.

Referenzen

Alte Arbeitskarten (übernommen, Karten-Dateien gelöscht): Karte 01 Rollen&Zuordnung, Karte 04 Organisationsstruktur/Zuständigkeit.