Konzepte

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

⚠️ Die Rolle „Einsatzkraft" hat einen eigenen Reiter — Häkchen bewirken dort aber nichts. Sie kann sich nicht anmelden (siehe Die 7 Rollen), also greift kein Recht, das Du ihr gibst. Ab Werk hat sie kein einziges; das ist Absicht und sollte so bleiben. Ihre Meldungsliste hängt nicht an einem Recht, sondern daran, dass ihr eine Meldung zugestellt wurde.

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 wird protokolliert — mit dem, was sich geändert hat, und mit wem. Ü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 . Praktisch, wenn Du Dich mal verklickt hast.

Drei Failsafes, die Dich schützen

1. Admin-Failsafe

Die Rolle admin hat jedes Recht — 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. Rechte, die es nur bei bestimmten Rollen gibt

Manche Permissions ergeben nur bei bestimmten Rollen Sinn. Beispiel: einsatz.view_all ist eine Recht, das die Sichtbarkeits-Grenze aufhebt für den Dispo — er kann damit alle Einsätze sehen statt nur die eigenen. Bei Admin/Lage/EL gibt es keinen Sichtbarkeits-Grenze 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 (fest eingebaute Regel, 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 Schwerpunkt-Grenze des SP-Dispos 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?

Sechs Dinge sind fest eingebaute Regel und können nicht administriert werden:

Die 51 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, mitteilung.durchsage, mitteilung.rueckmeldungen

⚠️ 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 eingegrenzter Dispo (ohne einsatz.view_all) kann nur eigene Einsätze löschen.

Wenn Du von einer älteren Version kommst: Die Moderation fremder Einsatz-Kommentare hängt am Schlüssel comment.delete („Einsatz-Kommentare moderieren"), nicht mehr an einsatz.delete. 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 die Schwerpunkt-Grenze — 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 Alarmierung über den eingestellten Zustellweg 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.

ℹ️ mitteilung.durchsage („Nachricht verschicken") öffnet die Seite Nachricht — erreichbar über den Knopf oben im Postfach, nicht über das Hauptmenü. Damit geht eine freie Meldung an eine Rolle oder eine Einheit — etwa „Sammelpunkt verlegt" —, bei Web Push direkt auf den Sperrbildschirm. Ohne das Recht gibt es weder den Knopf noch die Seite.

Eine einzelne Person ist als Empfänger möglich, sobald der Zustellweg Personen adressiert — also bei Web Push, nicht bei Telegram (dort wäre jede „Direktnachricht" ein Gruppenchat mit Mitlesern). Ein rechtebasierter Empfängerkreis (recht:…) wird dagegen immer abgewiesen — sonst ließe sich gezielt die Führung anfunken.

Per Default an bei Administrator, Einsatzleiter und Lage, zusätzlich an den Dispo vergebbar (manche Wehren organisieren die Lagemeldung dort). Nicht vergebbar an SP-Dispo (eine Nachricht ginge an alle und wäre damit ein Bruch seines Schwerpunkt-Grenzes), Gast und Einsatzkraft — sonst könnte jeder Alarm-Empfänger die ganze Wehr anfunken.

Beim Update einer bestehenden Installation trägt der Schema-Check das Recht einmalig für alle Rollen nach, die schon „Alarm manuell auslösen" (alarm.trigger_manual) haben — beides sind Führungshandlungen mit Breitenwirkung. Hast Du dieses Recht abweichend vom Standard verteilt, prüfe die Verteilung danach hier.

⚠️ mitteilung.rueckmeldungen („Rückmeldungen anderer sehen") öffnet die Klarnamen im Postfach. Wer es hat, sieht unter jeder Meldung, wer wie geantwortet hat — mit Namen und Zusatztext („Außerdem: Anna Komme, Bernd Später (bin in 10 Minuten da)"). Wer es nicht hat, sieht die eigene Antwort und die Anzahl der Zusagen; die Zahl sagt, ob man allein unterwegs ist, und verrät niemanden.

Per Default an bei Administrator, Einsatzleiter und Lage — dieselbe Runde, die auch die Sammelmeldung bekommt.

Angeboten wird das Häkchen nur bei Einsatzleiter, Lage und Dispo — genau wie bei der Nachricht. Beim Dispo kannst Du es also zusätzlich setzen; ab Werk hat er es nicht.

Bei Gast, Einsatzkraft und Schwerpunkt-Dispo gibt es das Häkchen gar nicht. Beim SP-Dispo ist das kein Versehen: Seine Sicht endet am Schwerpunkt, die Rückmeldungen kommen aber von der ganzen Wehr — das Häkchen hätte ihm die Anwesenheitsliste aller aufgeschlossen. Gast und Einsatzkraft bekommen grundsätzlich keine Klarnamen: nicht im Postfach, nicht über die Sammelmeldung und nicht auf der Seite Rückmeldungen.

Der Riegel sitzt an drei Stellen — im Katalog (das Häkchen wird nicht angeboten), im Dienst und beim Versand. Dieselbe Bauweise wie bei den gesperrten Rechten: Die unterste Ebene ist die, die wirklich zählt.

Bewusst ein eigenes Recht und nicht einsatz.view: Das hat auch die Rolle Gast — damit hätte jeder mit Login die vollständige Anwesenheitsliste der Wehr gelesen, samt Zusätzen wie „bin im Urlaub".

Beim Update einer bestehenden Installation trägt der Schema-Check das Recht einmalig für alle Rollen nach, die schon „Nachricht verschicken" (mitteilung.durchsage) haben: Wer die Wehr anfunken darf, führt — und darf sehen, wer kommt. Weicht Deine Verteilung vom Standard ab, prüfe sie danach hier.

Abschnitt

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

⚠️ abschnitt.create („Abschnitt anlegen") wirkt nur zusammen mit einsatz.edit. Abschnitte anzulegen verlangt 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 Schwerpunkt-Grenze des SP-Dispos (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

ℹ️ Web Push hat bewusst kein eigenes Recht. Die Verwaltung (Web Push: Schlüssel, Einladungen, Geräte-Liste) hängt an admin.config wie der übrige Meldungs-Bereich. Das Einrichten des eigenen Geräts dagegen darf jeder Angemeldete — die Schnittstelle dahinter schreibt das Gerät immer dem Konto der laufenden Sitzung zu und kann konstruktionsbedingt kein fremdes Konto treffen. Ein zusätzliches Häkchen wäre hier eine Hürde ohne Schutzwirkung.

Die Rolle Einsatzkraft kommt ganz ohne Anmeldung zu ihrem Gerät — über einen Einladungslink, der 14 Tage und genau einmal gilt. Er ist keine Anmeldung: Er schaltet ausschließlich das Anlegen eines Geräte-Eintrags frei, erzeugt keine Sitzung und öffnet keine Seite des Tagebuchs.

⚠️ admin.access schützt seit dem Rückkanal auch die Seite Rückmeldungen. Vorher genügte dort eine Anmeldung — der Menü-Eintrag war zwar an admin.access gebunden, die Seite selbst aber nicht. Da sie jetzt Klarnamen, freie Zusatztexte und den Einsatzbezug über die ganze Wehr zeigt, ist das Recht Pflicht.

Für Gast und Einsatzkraft reicht das Recht trotzdem nicht. Beide sind auf dieser Seite hart gesperrt, auch wenn ihnen jemand admin.access zuweist — dann meldet die Seite „Diese Übersicht zeigt Klarnamen und ist für Deine Rolle nicht vorgesehen." Es ist dieselbe Grenze wie beim Versand: An genau diese beiden Rollen geht auch die Sammelmeldung nicht (siehe Meldungen). Eine Regel, die nur auf einem der beiden Wege gilt, wäre keine.

Ein Schwerpunkt-Dispo bleibt zusätzlich auf die Einsätze seiner Schwerpunkte begrenzt — die Sichtbarkeits-Grenze gilt hier wie überall. Die Telegram-Zeilen mit dem Merker „alt" sieht er gar nicht: Sie tragen meist keinen Einsatzbezug und lassen sich deshalb nicht eingrenzen.

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 Dialog) 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 Sichtbarkeits-Grenze. 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.

Atemschutz

atemschutz.view, atemschutz.fuehren, atemschutz.freigeben, atemschutz.verknuepfen

ℹ️ Vier Rechte, weil es vier verschiedene Fragen sind. atemschutz.view ist das Leserecht (Übersicht, Tafel, Protokolle; dazu die AGT-Kennzeichen an den Einsatzkräften — auch das AGT hinter den Namen in den Rückmeldungen und auf dem Alarmmonitor) — damit lässt sich nichts erfassen. atemschutz.fuehren erlaubt, eine Überwachung anzulegen und eine freie als Überwacher zu übernehmen; wer führt, ist der Einzige, der darin schreiben darf. Default für beide: Einsatzleiter, Lage, Dispo und SP-Dispo.

⚠️ atemschutz.freigeben ist das Führungsrecht. Es erlaubt, eine laufende Überwachung an jemand anderen zu übergeben, ohne der bisherige Überwacher zu sein — gedacht für den Fall, dass dieser nicht mehr erreichbar ist. Es ist ROLE_SPECIFIC: Das Häkchen erscheint nur bei Einsatzleiter und Lage (der Administrator kommt über den Failsafe). Der bisherige Überwacher darf seine eigene Überwachung immer übergeben — das hängt an der Überwacher-Eigenschaft, nicht an diesem Recht. Dasselbe Recht erlaubt auch, eine offene Übergabe-Anfrage abzulehnen — und macht den Balken mit beiden Knöpfen sichtbar. Vorher hing das Ablehnen am Schreibrecht: Die Einsatzleitung durfte die folgenreiche Richtung gehen, bekam beim bloßen Wegräumen einer Anfrage aber „Das darfst Du nicht."

⚠️ Auch mit atemschutz.view gilt Dein Bereich. Liegt der Einsatz einer Überwachung außerhalb — beim SP-Disponenten der Regelfall —, zeigen Tafel, Protokoll, Ausdruck und die Schnittstelle dahinter statt der Namen der Atemschutzgeräteträger, des Erfassers und der Notiz einen Gedankenstrich. Truppnamen, Zeiten und Drücke bleiben sichtbar. Der Tablet-Zugang hat keinen Bereich, sondern den Zettel am Fahrzeug — für ihn ändert sich nichts.

⚠️ atemschutz.verknuepfen verbindet eine Überwachung nachträglich mit einem Einsatz. Wer sie ohne Einsatzbezug angelegt hat — am Fahrzeug ohne Verbindung ist das der Normalfall —, ordnet sie damit später zu. Dabei wandern die bereits erfassten Vorgänge mit ihrer Ereigniszeit in das Einsatzprotokoll, also revisionsfest in die Zeitleiste eines Einsatzes, den sich der Handelnde selbst aussucht. Deshalb ein eigenes Recht und nicht freigeben mitbenutzt, und deshalb ebenfalls ROLE_SPECIFIC: Das Häkchen erscheint nur bei Einsatzleiter und Lage (der Administrator kommt über den Failsafe). Wählbar sind nur offene Einsätze im eigenen Bereich, und nur einmal — eine Überwachung umzuhängen gibt es nicht.

⚠️ Eine Überwachung zu LÖSCHEN hängt an keinem Recht, sondern an der Rolle: allein der Administrator, allein in der AÜ-Liste unter Werkzeuge → Atemschutz. Dabei gehen Journal, Trupps, Personen und die Einträge im Einsatzprotokoll mit; wer es tat, steht im Audit-Protokoll des Einsatzes. Vergeben lässt sich das bewusst nicht — sonst wäre die Zusage, dass das Journal unantastbar ist, an einem Häkchen aufzuheben.

⚠️ Der Tablet-Zugang kennt diese Häkchen nicht. Wer über den QR-Code kommt, hat kein Konto; für ihn ist der Zugang selbst die Erlaubnis — sehen und führen, sonst nichts. Siehe Atemschutz verwalten.

⚠️ Dasselbe gilt für einen Bildschirm ohne Anmeldung. Er zeigt das AGT hinter den Namen, ohne dieses Recht zu kennen — die einzige Grenze ist dort der Modulschalter. Ist die Atemschutzüberwachung aus, verschwindet das Kennzeichen auch am Wandschirm.

⚠️ Das Recht allein öffnet nichts. Ist die Atemschutzüberwachung unter Atemschutz verwalten ausgeschaltet, bleibt der ganze Bereich für jeden unsichtbar.

Bei einem Update einer bestehenden Installation zieht der Schema-Check atemschutz.view für jede Rolle mit einsatz.comment nach, atemschutz.fuehren für jede mit einsatz.status, atemschutz.freigeben für jede mit alarm.trigger_manual und atemschutz.verknuepfen für jede, die schon atemschutz.freigeben hat — einmalig und nur, solange das jeweilige Recht noch nirgends vergeben ist. Danach entscheidest Du hier.

Das Führen hängt bewusst an einem Schreibrecht und nicht am Kommentarrecht: Hast Du einsatz.comment breiter vergeben als die Vorgabe, bekämen diese Rollen sonst ungefragt die Schreibhoheit über eine laufende Atemschutzüberwachung.

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