Konzepte

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

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.

ℹ️ Geprüft wird die effektive Rolle (Basis plus eine gerade geliehene, „Highlander"-Vereinigung) — seit v4.7.5 darf also auch vergeben, wer Einsatzleiter oder Lage nur geliehen hat, sofern die jeweilige Rolle das Häkchen trägt. Bis v4.7.0 wurde ausschließlich die feste Basis-Rolle geprüft; die damalige Leitplanke gegen endlose Weitergabe-Ketten sitzt jetzt in einer Laufzeit-Deckelung: Eine so vergebene Rolle endet spätestens zum Ablauf der eigenen geliehenen Rolle des Vergebenden. Unabhängig vom Häkchen darf zusätzlich eine per Alarm-Knopf übernommene Lage vergeben (Code-Logik, nicht administrierbar) — der Notfall-Mechanismus soll nicht von einem Admin-Häkchen abhängen, das im Ernstfall gerade niemand setzen kann. 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 46 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 („Status setzen") ist das Recht für jeden von Hand ausgelösten Status-Wechsel — überall. Es entscheidet an allen Stellen, an denen Du den Status eines Einsatzes selbst umstellst: das Dropdown in der Einsatz-Zeile der Übersicht, die Sammelaktion „Status" in der Bulk-Leiste, das Dropdown im Einsatz-Detail, der Knopf „Einsatz erledigen" und das Status-Feld im Bearbeiten-Formular. Wer das Recht nicht hat, bekommt diese Bedienelemente gar nicht erst zu sehen — im Bearbeiten-Formular steht der Status dann nur als Text da. Auch die Schnittstellen dahinter weisen einen Status-Wechsel ohne dieses Recht ab. einsatz.edit („Einsatz bearbeiten") allein genügt dafür nicht.

Dasselbe gilt beim Anlegen eines Einsatzes: Ein vom Standard Neu abweichender Status verlangt einsatz.status, der Wert Abgeschlossen zusätzlich einsatz.abschluss — sonst ließe sich das Vier-Augen-Prinzip dadurch umgehen, dass ein Einsatz gleich abgeschlossen angelegt wird.

Nicht betroffen sind die automatischen Übergänge: Wer einen Disponenten bzw. ein Einsatzmittel zuweisen darf, schiebt den Einsatz damit weiterhin auf „Disponent" bzw. „In Bearbeitung" — auch ohne einsatz.status. Der Status folgt dort der Arbeit; siehe mehr zu Status.

ℹ️ 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. Der Knopf „Einsätze abschließen" in der Einsatz-Übersicht — ein Fenster, das die erledigten Einsätze des Bereichs gesammelt zum Abschluss anbietet — erscheint folgerichtig nur, wenn beide Rechte gesetzt sind: einsatz.abschluss und einsatz.status (Abschließen ist ein Status-Wechsel). Mehr unter mehr zu Status und in der Einsatz-Übersicht.

⚠️ Für eigene Rollen-Zuschnitte wichtig: Alle Standard-Rollen, die Einsätze bearbeiten dürfen, tragen einsatz.edit und einsatz.status gemeinsam — für sie ändert sich nichts. Hast Du Dir aber eine Rolle gebaut, die nur einsatz.edit hat, kann sie keinen Status mehr setzen. Prüfe solche Rollen im Rollen-Editor und setze das Häkchen „Status setzen" dazu, wenn sie es weiterhin können soll.

ℹ️ 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

⚠️ abschnitt.create („Abschnitt anlegen") wirkt jetzt tatsächlich — und nur zusammen mit einsatz.edit. Der Schlüssel stand seit jeher im Rollen-Editor und ließ sich an- und abwählen, geprüft hat ihn aber niemand: Zum Bilden von Abschnitten genügte faktisch das Bearbeiten-Recht, das Häkchen war wirkungslos. Seit dieser Version braucht das Anlegen beides — einsatz.edit (darf an diesem Einsatz überhaupt arbeiten) und abschnitt.create (darf Abschnitte anlegen). Fehlt eines von beiden, erscheinen der Toolbar-Knopf „Abschnitte bilden" bzw. „Abschnitt hinzufügen" und das zugehörige Fenster auf der Einsatz-Detailseite gar nicht erst; die Schnittstelle dahinter weist den Versuch ebenfalls ab.

Für eigene Rollen-Zuschnitte wichtig: Alle Standard-Rollen, die Abschnitte bilden dürfen (Lage, EL, Dispo, SP-Dispo; Administrator über den Failsafe), tragen beide Rechte — für sie ändert sich nichts. Nur bei selbst gebauten Rollen kann es Unterschiede geben, und zwar in beide Richtungen: Wer abschnitt.create abgewählt hatte (in der Annahme, das tue etwas), verliert die Funktion jetzt wirklich — Häkchen wieder setzen, wenn die Rolle Abschnitte bilden können soll. Wer umgekehrt einsatz.edit abgewählt und abschnitt.create stehen gelassen hat, gewinnt dadurch keine Rechte dazu: Ohne Bearbeiten-Recht bleibt das Anlegen gesperrt.

ℹ️ abschnitt.em_assign („EMs zu Abschnitt zuweisen") gilt für jeden Weg, auf dem ein Einsatzmittel an einem Abschnitt landet — nicht nur für die Drop-Zone auf der Abschnitts-Seite. Auch die beiden Nebenwege verlangen es: die Einsatzmittel-Vorbelegung im Modal „Abschnitte bilden" und ein optionaler Abschnitts-Anteil beim Zuweisen eines EM zum Einsatz. Fehlt das Recht, läuft die Hauptaktion trotzdem durch (die Abschnitte entstehen, das EM hängt am Einsatz) — nur der Abschnitts-Anteil entfällt, und die Rückmeldung sagt Dir das ausdrücklich. Das Recht em.assign (EM an den Einsatz hängen) deckt diesen Schritt also nicht mit ab.

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. Geprüft wird die effektive Rolle — seit v4.7.5 darf also auch vergeben, wer Einsatzleiter oder Lage nur geliehen hat; die Kette wird dabei über die Laufzeit gedeckelt (endet spätestens mit der eigenen geliehenen Rolle), nicht mehr über ein Verbot. Unabhängig vom Häkchen darf zusätzlich die per Alarm-Knopf übernommene Lage vergeben. Vollständige Anleitung: Einsatz-Rollen.

Bevölkerungswarnung

mowas.view, mowas.create, mowas.release, mowas.export

ℹ️ Sehen und Herunterladen sind getrennte Rechte. mowas.view deckt nur das Lesen ab (Liste, Detail, Warn-Radien); seit v4.7.5 braucht das Herunterladen der Formulare (PDF/Excel) zusätzlich mowas.export. mowas.create (anlegen/bearbeiten/operative Statuswechsel) und mowas.release (Freigabe, Vier-Augen) sind unverändert. Default: Lage und Einsatzleiter haben view + export sowie je eines von create/release; der Disponent hat per Default nur mowas.view (Erstellen und Herunterladen sind ihm zuschaltbar, aber bewusst nicht voreingestellt). Schwerpunkt-Dispo und Gast können keines der vier Rechte erhalten — Warnungen tragen bewusst keinen Scope-Filter. Details: Bevölkerungswarnung.

Wetter

wetter.view

ℹ️ wetter.view („Wetter sehen") deckt die Wetterseite, die Wetter-Ebenen von Lagekarte und Einsatzkarte sowie die Wetter-Zeile im Einsatz-Detail ab. Reines Leserecht — das Modul ist passiv und schreibt von sich aus nichts; das Übernehmen ins Tagebuch verlangt zusätzlich einsatz.comment. Default: alle Rollen bis hinunter zum Gast — Wetter ist eine Lage-Information wie die Karte selbst und enthält keine personenbezogenen Daten.

⚠️ Das Recht allein öffnet nichts. Wetter ist ein zubuchbares Modul: Ist es unter Wetter verwalten nicht freigeschaltet, bleibt es für alle unsichtbar, unabhängig von diesem Häkchen.

Bei einem Update einer bestehenden Installation zieht der Schema-Check das Recht für jede Rolle nach, die schon lagekarte.view hat — einmalig, danach entscheidest Du hier.

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