Konzepte

Die Berechtigungen pro Rolle pflegst Du unter /admin/rollen.php. Diese Seite zeigt eine Häkchen-Matrix: links die Rollen, oben die 41 atomaren Permissions, gruppiert nach Bereich (Einsatz, Abschnitt, Schwerpunkt, Einsatzmittel, Kommentar-Anhänge, Karten & Tools, Einsatz-Rollen, Administration).

So pflegst Du eine Rolle

1. Wähle in der oberen Tab-Leiste die Rolle aus, die Du anpassen willst.
2. Setze oder entferne die Häkchen.
3. Klick auf „Speichern" — die Änderung wird sofort wirksam, ohne Logout/Re-Login der betroffenen User.
4. Jede Änderung landet im RoleAuditService mit Diff und User. Über /admin/log-dashboard.php kannst Du nachsehen, wer was wann geändert hat.

„Reset auf Default"

Pro Rolle gibt es einen Button „Default wiederherstellen". Er setzt die Häkchen wieder auf die im Code festgelegten Standardwerte (PermissionCatalog::DEFAULTS). Praktisch, wenn Du Dich mal verklickt hast.

Drei Failsafes, die Dich schützen

1. Admin-Failsafe

Die Rolle admin bekommt in PermissionService::userCan() immer true zurück — auch wenn alle Häkchen leer sind. So kannst Du Dich nicht selbst aussperren.

2. Locked-Permissions

Bestimmte Permission/Rolle-Kombinationen sind dauerhaft erzwungen. Beispiele: sp_dispo muss schwerpunkt.view immer haben — sonst wäre die Rolle funktionslos. Und dispo hat das Recht „Als Disponent arbeiten" (dispo.act_as) fest gesetzt — der Disponent ist per Definition immer Disponent. Du siehst solche gesperrten Häkchen mit einem 🔒-Symbol und einem Hover-Text „Diese Berechtigung ist für die Rolle erforderlich und kann nicht entzogen werden".

Auch wenn jemand die Sperre per direktem API-Call umgehen wollte: Der Service schreibt die Locked-Permissions beim Speichern automatisch mit rein.

3. ROLE_SPECIFIC_PERMS

Manche Permissions ergeben nur bei bestimmten Rollen Sinn. Beispiel: einsatz.view_all ist eine Scope-Override-Permission für den Dispo — er kann damit alle Einsätze sehen statt nur die eigenen. Bei Admin/Lage/EL gibt es keinen Scope-Filter zu umgehen, also wäre die Permission da sinnlos.

ℹ️ Ohne einsatz.view_all startet die ETB-Übersicht für einen Dispo beim ersten Aufruf vorgefiltert auf die eigenen zugewiesenen Einsätze (mit Hinweis und „Alle anzeigen"-Link). Mit einsatz.view_all entfällt diese Vorauswahl. Siehe Einsatz-Übersicht.

Ein zweites Beispiel ist dispo.act_as („Als Disponent arbeiten"): Das Häkchen erscheint nur bei Dispo, Lage und Einsatzleiter. Bei Dispo ist es fest gesetzt (siehe Locked-Permissions oben), bei Lage und Einsatzleiter kannst Du es nach Bedarf setzen. Für Schwerpunkt-Dispo und Gast taucht es gar nicht erst auf — der SP-Dispo soll außerhalb seiner Schwerpunkte kein Disponent werden.

ℹ️ Und der Administrator? Beim Admin wird das Häkchen — wie bei allen Rechten — gar nicht erst angezeigt. Er bekommt dispo.act_as aber über den Admin-Failsafe (er darf ohnehin alles) und erscheint deshalb ebenfalls in den Disponenten-Auswahllisten. Du kannst einen Admin also wie einen Dispo zuweisen, ohne ihm das Recht eigens geben zu müssen.

Ein drittes Beispiel ist user.assign_temp_role („Einsatz-Rollen vergeben", Gruppe Einsatz-Rollen): Das Häkchen erscheint nur bei Einsatzleiter und Lage. Beim Einsatzleiter ist es per Default gesetzt, bei der Lage kannst Du es zuschalten. Für Dispo, Schwerpunkt-Dispo und Gast taucht es gar nicht erst auf — sonst könnte sich ein Stellvertreter selbst höhere Vertreter schaffen. Der Administrator bekommt es wie alle Rechte über den Failsafe. Mehr dazu unter Einsatz-Rollen.

⚠️ Dieses Recht wird bewusst gegen die feste Rolle geprüft (nicht gegen eine geliehene): Wer nur temporär Einsatzleiter ist, darf nicht weiter Einsatz-Rollen vergeben. Einzige Ausnahme (Code-Logik, nicht administrierbar): eine per Alarm-Knopf übernommene Lage darf Einsatz-Rollen vergeben — sofern die Rolle Lage dieses Häkchen hat (per Default aus); die Kette endet dort, von ihr ernannte Rollen verleihen nicht weiter. Siehe Einsatz-Rollen.

Auch die Schwerpunkt-Mutationsrechte (schwerpunkt.edit, schwerpunkt.assign_einsatz, schwerpunkt.delete, schwerpunkt.close) und abschnitt.delete werden im Rollen-Editor nur bei Einsatzleiter und Lage angeboten — Führungsaufgaben gehören in Führungshand. Für Dispo, Schwerpunkt-Dispo und Gast tauchen diese Häkchen gar nicht erst auf (der Administrator bekommt sie über den Failsafe). Beim SP-Dispo greift zusätzlich der SP-Dispo-Scope als Code-Leitplanke.

Solche Permissions tauchen in der UI nur bei der jeweiligen Rolle auf und können bei den anderen Rollen gar nicht erst gesetzt werden.

Was ist KEIN Permission-Häkchen?

Vier Dinge sind Code-Logik und können nicht administriert werden:

Die 41 Permissions im Überblick

Einsatz

einsatz.view, einsatz.view_all, einsatz.create, einsatz.edit, einsatz.delete, einsatz.status, einsatz.abschluss, einsatz.reopen, einsatz.comment, comment.delete, dispo.act_as, alarm.trigger_manual

⚠️ einsatz.delete („Einsatz löschen") ist ein Entity-Löschrecht — kein Kommentar-Recht. Wer es hat, kann in der Einsatz-Übersicht einen Einsatz endgültig löschen — per Papierkorb in der Zeile oder als Bulk-Aktion, immer mit Pflicht-Begründung (landet im Anwendungsprotokoll). Der Einsatz wird samt Abschnitten, Einsatzmitteln, Kommentaren, Anhängen und Audit hart entfernt und ist nicht wiederherstellbar. Per Default an bei Administrator, Einsatzleiter und Lage; pro Rolle abwählbar und an weitere Rollen delegierbar. Ein gescopter Dispo (ohne einsatz.view_all) kann nur eigene Einsätze löschen.

Umbenennung beim Update: Bis zu dieser Version hieß einsatz.delete zwar „Einsatz löschen", steuerte faktisch aber nur die Moderation fremder Einsatz-Kommentare. Diese Kommentar-Moderation läuft jetzt über den neuen Schlüssel comment.delete („Einsatz-Kommentare moderieren"). Der Schema-Check nach dem Update benennt die bestehenden einsatz.delete-Zuordnungen aller Rollen einmalig auf comment.delete um (bewahrt so die bisherige Moderation) und setzt einsatz.delete als neues Löschrecht für Administrator, Einsatzleiter und Lage. Prüfe danach im Rollen-Editor, ob die Verteilung Deinen Vorstellungen entspricht.

ℹ️ einsatz.status vs. einsatz.abschluss (Vier-Augen-Prinzip). einsatz.status deckt den Status-Lebenszyklus bis „Erledigt" ab — inklusive des „Einsatz erledigen"-Buttons. Der finale Schritt auf „Abgeschlossen" verlangt zusätzlich einsatz.abschluss und liegt per Default bei Lage, Einsatzleiter und Admin. So kann ein Dispo (der einsatz.status, aber nicht einsatz.abschluss hat) einen Einsatz erledigen, aber nicht abschließen — der Abschluss bekommt ein zweites Augenpaar. Die Sperre wirkt überall, wo abgeschlossen wird: Status-Dropdown, Bulk-Aktion und der Abschluss-Arbeitsplatz. Das Recht blendet außerdem in der Einsatz-Übersicht den Knopf „Einsätze abschließen" ein — ein Fenster, das die erledigten Einsätze des Bereichs gesammelt zum Abschluss anbietet. Mehr unter mehr zu Status und in der Einsatz-Übersicht.

ℹ️ dispo.act_as („Als Disponent arbeiten") entscheidet, wer in den Disponenten-Auswahllisten auftaucht und als Disponent zugewiesen werden kann — bei Einsätzen, Abschnitten und Schwerpunkten. Per Default hat nur „Dispo" das Recht (dort fest gesetzt, siehe Locked-Permissions); „Lage" und „Einsatzleiter" kannst Du es zusätzlich geben. Der Administrator erscheint ebenfalls in den Listen — nicht über ein Häkchen (das wird ihm wie bei allen Rechten nicht angezeigt), sondern über den Admin-Failsafe, der ihm jedes Recht zugesteht. „Schwerpunkt-Dispo" und Gast bekommen das Recht dagegen nicht (das Häkchen wird ihnen gar nicht angezeigt). Der SP-Dispo bleibt davon unberührt: Er führt die Einsätze und Abschnitte seiner Schwerpunkte weiterhin über den SP-Scope — dispo.act_as ändert daran nichts und macht ihn nicht zum Disponenten außerhalb seiner Schwerpunkte.

ℹ️ alarm.trigger_manual („Alarm manuell auslösen") blendet in der Einsatz-Übersicht den Knopf „Alarm auslösen" ein. Damit löst Du eine Alarmregel (z. B. UW-ERSTALARM) per Hand aus, wenn die Leitstelle keine Mail schickt — Basis-Einsatz + Folge-Einsätze werden angelegt und es geht eine echte Telegram-Alarmierung raus (mit 60-Sekunden-Cooldown gegen Doppelauslösung). Per Default bei Lage und Einsatzleiter gesetzt, Administrator über den Failsafe; nicht an Dispo, SP-Dispo oder Gast vergeben. Eine geliehene Einsatz-Rolle (temp EL/Lage) zählt hier mit — anders als beim Vergeben von Einsatz-Rollen. Vollständige Anleitung: Alarm-Regeln → Manuelle Auslösung.

Abschnitt

abschnitt.view, abschnitt.create, abschnitt.edit_stamm, abschnitt.delete, abschnitt.status, abschnitt.reopen, abschnitt.em_assign, abschnitt.comment

Schwerpunkt

schwerpunkt.view, schwerpunkt.create, schwerpunkt.edit, schwerpunkt.delete, schwerpunkt.close, schwerpunkt.assign_einsatz, schwerpunkt.export

ℹ️ schwerpunkt.edit vs. schwerpunkt.close (Vier-Augen-Prinzip). schwerpunkt.edit deckt das Bearbeiten ab — Stammdaten, EM-Pool, Orte. Den Schwerpunkt erledigen oder abschließen (Status-Wechsel auf „Erledigt" bzw. „Abgeschlossen"; interne Keys geschlossen/archiviert, im Rollen-Editor als „Schwerpunkt schließen / archivieren" beschriftet) verlangt zusätzlich schwerpunkt.close und liegt per Default bei Lage, Einsatzleiter und Admin — analog zum einsatz.abschluss beim Einsatz. So kann jemand mit schwerpunkt.edit einen Schwerpunkt pflegen, aber nicht erledigen. Der Service erzwingt das Recht serverseitig, unabhängig vom Endpoint. Hinzu kommen zwei Sperren: Erledigt ist erst möglich, wenn alle Einsätze des Schwerpunkts mindestens erledigt sind, und einen abgeschlossenen Schwerpunkt reaktiviert nur ein Administrator (Basis-Rolle, nicht über eine geliehene Einsatz-Rolle). Mehr in der Schwerpunkt-Übersicht.

Einsatzmittel

em.assign, em.uoert_create, em.stammdaten

ℹ️ em.assign deckt die gesamte EM-Disposition ab: EMs per Drag&Drop an Einsätze zuweisen/entfernen und sie auf der Einsatzmittel-Übersicht per Karten-Klick entlassen bzw. reaktivieren. Für SP-Disponenten greift dabei zusätzlich der SP-Dispo-Scope (nur EMs aus den eigenen Schwerpunkt-Pools).

Anhänge

anhang.download_image, anhang.download_document

Admin

admin.access, admin.users, admin.roles, admin.config, admin.stammdaten, admin.export

Karten & Tools

lagekarte.view, hydranten.view

Einsatz-Rollen

user.assign_temp_role

ℹ️ user.assign_temp_role („Einsatz-Rollen vergeben") schaltet den Button „Einsatz-Rollen" auf der Einsatz-Übersicht (öffnet ein Modal) frei. Damit leihst Du einem anderen Benutzer befristet (max. 48 h) die Rolle Einsatzleiter oder Lage — sie wirkt sofort ohne Neuanmeldung, das höhere Recht gewinnt („Highlander"). Default an beim Einsatzleiter, optional für die Lage; nicht vergebbar an Dispo/SP-Dispo/Gast. Administrator und Schwerpunkt-Dispo sind als Ziel ausgeschlossen, und eine geliehene Rolle kann nicht weiterverliehen werden (das Recht wird gegen die Basis-Rolle geprüft) — einzige Ausnahme ist die per Alarm-Knopf übernommene Lage. Vollständige Anleitung: Einsatz-Rollen.

Welche Permission Default für welche Rolle gesetzt ist, siehst Du direkt in der Matrix mit den vorbelegten Häkchen.

Best Practices

ℹ️ Im Zweifel: weniger. Du kannst jederzeit Permissions nachschalten. Eine zu großzügige Default-Belegung ist im Live-Betrieb schwerer zurückzudrehen.

ℹ️ Vor dem Ausrollen testen. Lege Dir Test-User pro Rolle an, melde Dich an und prüfe, dass alle Aktionen funktionieren, die funktionieren sollen — und nichts, was nicht soll.

⚠️ Achtung: Wenn Du einer Rolle eine Permission gibst, gilt sie sofort für alle User dieser Rolle — auch für die schon eingeloggten. Permission-Checks laufen pro Request.

Was als nächstes?

• Die 6 Rollen — Konzept zur Erinnerung
• Einsatz-Rollen — das Recht „Einsatz-Rollen vergeben" in der Praxis
• Admin-Übersicht — wo die Rollen-Seite im Admin-Bereich liegt
• Diagnose & Werkzeuge — wo Du Permission-Änderungen im Log nachvollziehst