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