FAQ & Glossar

FAQ

Wenn etwas hakt, schau zuerst hier — die meisten Probleme sind mit ein bis drei Klicks gelöst. Fachbegriffe schlägst Du im Glossar nach.

Login / Berechtigungen

Ich sehe keine Einsätze, obwohl welche da sind.

Du bist wahrscheinlich als Dispo oder SP-Dispo eingeloggt. Der Dispo-Eigentums-Filter zeigt nur Einsätze, bei denen Du als Dispo eingetragen bist oder die Du selbst angelegt hast. Der SP-Dispo sieht nur Einsätze aus seinen Schwerpunkten.

Lösung:

  • Als Admin → /admin/rollen.php → der Rolle die Permission einsatz.view_all über den Rollen-Editor geben (nur für Dispo sichtbar). Permissions sind rollenbasiert, nicht pro Benutzer.
  • Oder: einen Admin bitten, Dir den Einsatz als Dispo zuzuweisen.

„403 Forbidden" beim Klick auf eine Aktion.

Dir fehlt die nötige Permission. Bitte den Admin, Dir die passende Permission über /admin/rollen.php zuzuteilen. Siehe Permission-Matrix.

Ich habe mein Passwort vergessen.

Auf der Login-Seite „Passwort vergessen?" klicken, Benutzername oder hinterlegte E-Mail eingeben — Du bekommst einen Link (30 Minuten gültig, einmalig), über den Du ein neues Passwort vergibst. Das setzt voraus, dass an Deinem Konto eine E-Mail-Adresse hinterlegt ist und der Betreiber den SMTP-Versand eingerichtet hat.

Geht das nicht (keine E-Mail am Konto, SMTP nicht eingerichtet): Admin → /admin/users.php → Deinen User auswählen → E-Mail nachtragen oder „Passwort zurücksetzen". Im Ernstfall (alle Admin-Passwörter weg) muss in der DB direkt das Passwort-Hash-Feld zurückgesetzt werden — sprich uns an.

„Passwort vergessen": Die Reset-Mail kommt nicht an.

Der Reihe nach prüfen:

  1. Spam-/Junk-Ordner checken — die Mail kommt von der unter SMTP_FROM konfigurierten Absender-Adresse.
  2. E-Mail am Konto hinterlegt? Nur Konten mit Adresse bekommen einen Link. Ohne Adresse erscheint stattdessen ein Admin-Hinweis — dann trägt der Admin die Adresse unter /admin/users.php nach (oder setzt das Passwort direkt).
  3. SMTP überhaupt eingerichtet? Steht in config/.env kein SMTP_HOST, ist die Funktion aus und meldet „… E-Mail-Versand ist auf diesem System nicht eingerichtet". Siehe den SMTP-Block in Konfiguration.
  4. Link unbrauchbar / ohne Server-Adresse? org_url in /admin/config.php auf die ETB-URL setzen (z. B. https://etb.example.de) — daraus wird der Link gebaut.
  5. „Zu viele Anfragen"? Ein Rate-Limit bremst wiederholtes Anfordern — ein paar Minuten warten und erneut versuchen.
  6. Versand-Fehler? SMTP-Zugangsdaten/Port/Verschlüsselung prüfen; Details stehen im Log-Dashboard (/admin/log-dashboard.php, Modul USER).

Warum kann ich mich gerade nicht einloggen — „Bitte warte noch N Sekunden"?

Das ist die Brute-Force-Bremse und kein Defekt. Nach 5 fehlgeschlagenen Login-Versuchen (pro Benutzername + IP-Adresse) schaltet das ETB zwischen zwei weiteren Versuchen eine steigende Pflicht-Wartezeit — sie beginnt bei 2 Sekunden und verdoppelt sich bis maximal 60 Sekunden. So braucht ein Angreifer für einen Wörterbuch-Angriff Tage statt Sekunden, während ein vertippter Kamerad schlimmstenfalls eine Minute wartet.

Was Du tun kannst:

  • Einfach die angezeigte Zeit abwarten und es dann nochmal versuchen — mit dem richtigen Passwort.
  • Ein erfolgreicher Login setzt den Zähler sofort zurück.
  • Es gibt keine dauerhafte Sperre: Tut sich eine Weile nichts, löst sich die Bremse von selbst auf (die Fehlversuche zählen nur innerhalb einer Stunde, gespeicherte Einträge werden spätestens nach 24 Stunden gelöscht).

ℹ️ Die Bremse zählt pro Konto + IP. Im Gerätehaus teilen sich oft mehrere Kameraden eine IP — die Wartezeit gilt aber nur für das jeweilige Benutzerkonto, nicht für die ganze Wache. Ein Admin kann niemanden „freischalten": es gibt bewusst keine harte Sperre, die man aufheben müsste.

Ich habe versehentlich alle Häkchen beim Admin abgewählt.

Kein Problem. Der Admin-Failsafe im PermissionService gibt für ROLE_ADMIN immer true zurück, egal was in der DB steht. Du bist nicht ausgesperrt.

Ich habe die Rolle eines Benutzers geändert — wann wirkt das?

Sofort. Rolle, Aktiv-Status und Einsatz-Rollen werden bei jedem Seitenaufruf frisch aus der Datenbank geprüft. Der betroffene Benutzer muss sich nicht neu anmelden — beim nächsten Klick gilt die neue Rolle.

Ich wurde mitten in der Arbeit ausgeloggt.

Wahrscheinlich hat ein Admin Dein Konto auf inaktiv gesetzt oder Dein Passwort zurückgesetzt — beides beendet laufende Sitzungen sofort beim nächsten Seitenaufruf. Frag den Admin; ist das Konto wieder aktiv, kannst Du Dich normal neu anmelden. (Daneben gibt es das normale Sitzungs-Timeout nach 12 Stunden Inaktivität.)

Im Einsatz-Rollen-Modal fehlt ein Benutzer, dem ich eine Rolle leihen will.

Drei Gründe sind möglich:

  • Der Benutzer ist inaktiv — nur aktive Konten erscheinen.
  • Er ist Administrator oder Schwerpunkt-Dispo — diese beiden nehmen am Einsatz-Rollen-System nicht teil.
  • Es bist Du selbst — sich selbst kann man keine Einsatz-Rolle geben.

Mehr dazu unter Einsatz-Rollen.

Ich sehe den Button „Einsatz-Rollen" auf der Einsatz-Übersicht nicht.

Der Button (zwischen „Schwerpunkt erstellen" und „Alarm auslösen") verlangt das Recht „Einsatz-Rollen vergeben" (user.assign_temp_role) — per Default haben es Einsatzleiter und Admin, optional auch die Lage. Wichtig: Es zählt Deine feste Rolle. Wer selbst nur temporär Einsatzleiter ist (per Einsatz-Rolle), sieht den Button bewusst nicht — eine geliehene Rolle kann nicht weiterverliehen werden. Einzige Ausnahme: die per Alarm-Knopf übernommene Lage darf Einsatz-Rollen vergeben, sofern die Rolle Lage das Recht hat (siehe Einsatz-Rollen).

Neben meinem Benutzernamen im Menü steht ein roter Blitz-Knopf — was ist das?

Eine Alarm-Regel mit konfiguriertem Alarm-Knopf hat ausgelöst: Das ETB bietet einmalig eine Einsatz-Rolle (Lage oder Einsatzleiter) zur Selbst-Übernahme an — für den Fall, dass gerade keine Führungsrolle im ETB ist. Als Disponent (ohne aktive Einsatz-Rolle) übernimmst Du die Rolle per Klick und Bestätigung; sie wirkt sofort, und der Knopf verschwindet danach für alle. Hast Du bereits höhere Rechte, bietet der Klick stattdessen das Entschärfen des Angebots an. Details: Einsatz-Rollen.

Cron / Mail-Verarbeitung

Es kommen keine neuen Einsätze rein.

Erste Anlaufstelle: /admin/system-status.php — wie alt ist der letzte Cron-Lauf?

  • Älter als 10 Min: Cron läuft nicht. Crontab prüfen.
  • Aktuell, aber keine Mails: Mail-Postfach prüfen, Subject-Filter in /admin/config.php checken (mail_subject_alarm / mail_subject_unwetter).
  • Mails kommen an, aber kein Einsatz: Mail-Parser-Log unter /admin/log-dashboard.php prüfen.

„Cron läuft nicht."

crontab -l -u www-data    # ist der Job da?
sudo tail -f /var/log/syslog | grep CRON    # läuft er?
curl "https://etb.example.de/cron.php?token=..." # manuell triggern

Wenn der manuelle Curl-Aufruf eine sinnvolle JSON-Response liefert, ist es ein Cron-Setup-Problem (Crontab nicht aktiv). Sonst ist es ein ETB-Problem — Webserver-Logs prüfen.

Cron-Token vergessen.

/admin/config.php → Setting cron_token → Wert kopieren. Wenn Du den auch nicht mehr aufrufen kannst (kein Admin-Zugang), in der DB: SELECT value FROM konfig_hilfsmittel WHERE name = 'cron_token'.

Stichwort-Katalog

Im Einsatz-Formular fehlt mein Stichwort / die Kategorie ist leer.

Im zweiten Auswahlfeld stehen nur aktive Einträge des Stichwort-Katalogs der gewählten Kategorie. Fehlt Dein Stichwort, ist der passende Eintrag entweder inaktiv oder noch gar nicht angelegt — und eine leere Kategorie hat schlicht keine aktiven Stichworte.

Sofort weiterarbeiten: Als Kategorie „— Freitext —" wählen, dann tippst Du das Stichwort frei ein. Dauerhaft beheben: den Katalog unter Admin → Stammdaten → Stichwort-Katalog pflegen (Eintrag anlegen oder auf „aktiv" setzen).

Nach einer Präfix-Änderung sind die Anzeige-Stichworte anders / greifen Alarm-Regeln nicht mehr?

Das ist erwartet. Über „Ausblend-Präfixe → Jetzt anwenden" berechnet das ETB die Anzeige-Varianten aller Katalog-Einträge neu (ein führendes passendes Präfix wird abgeschnitten) — auch von Hand überschriebene Anzeigen, wenn sie vom abgeleiteten Wert abweichen.

Wichtig für Alarm-Regeln: Deren Trigger-Stichworte zielen auf die Anzeige-Variante. Änderst Du die Präfixe, kann sich diese Variante verschieben — prüfe danach die Trigger-Stichworte Deiner Alarm-Regeln, sonst feuern sie nicht mehr. Der Stichwort-Katalog weist beim Anwenden selbst darauf hin.

Telegram

Telegram sendet nicht.

Reihenfolge:

  1. /admin/telegram-selftest.php öffnen — was sagt der Selftest?
  2. Wenn Token ungültig: BotFather → /mybots → richtiges Token kopieren.
  3. Wenn Chat-IDs falsch: @RawDataBot einladen, neue IDs holen.
  4. Bot ist in den Ziel-Chats Mitglied? Bot muss in jedem Chat einmalig per /start angeschrieben werden.

Antworten aus dem Chat kommen nicht als Kommentar an.

Webhook ist nicht oder falsch gesetzt. /admin/webhook-status.php öffnen → „Webhook setzen" klicken. Voraussetzung: Deine ETB-URL ist über HTTPS mit gültigem Zertifikat erreichbar.

„403 Webhook Error" im Log.

Das webhook_secret stimmt nicht mit dem überein, was Telegram mitschickt. Wahrscheinlich hast Du das Secret nach dem Setzen geändert. Lösung: /admin/webhook-status.php → Webhook neu setzen.

Datenbank / Schema

Eine Aktion meldet „Interner Fehler — Details im Log-Dashboard."

Das ETB zeigt bei unerwarteten Fehlern bewusst keinen technischen Text mehr im Browser (keine SQL-Meldungen, Pfade oder Tabellennamen) — solche Interna gehören nicht zum Endnutzer. Was wirklich passiert ist, steht im Klartext im Log-Dashboard (/admin/log-dashboard.php). Gezielte Hinweise wie „Name fehlt." oder „Einsatzmittel ist aktuell im Einsatz" siehst Du weiterhin direkt — die sind als bewusste Validierungsmeldungen vom Maskieren ausgenommen.

ℹ️ Wenn der Browser Dir gar nichts anzeigt (weiße Seite, statt einer Meldung), liegt der Grund ebenfalls im Log: das ETB schreibt PHP-Fehler grundsätzlich ins Log statt auf den Bildschirm (display_errors ist serverseitig aus). Schau ins PHP-Error-Log (siehe „Wenn nichts hilft" am Ende).

„Table doesn't exist" / 500-Fehler nach Update.

Schema-Migration nicht gelaufen. /admin/schema-check.php öffnen → „Reparieren" — die fehlenden Tabellen, Spalten und Defaults werden migriert.

Der Schema-Banner in der Sidebar zeigt automatisch an, wenn das fällig ist.

Schema-Banner geht nicht weg, obwohl ich migriert habe.

Der globale missingTables()-Check ist gecached (1 h pro Session). Logout + Login löst den Cache. Oder Browser-Tab schließen und neu öffnen.

Die Page-spezifischen Feature-Banner (z. B. auf /admin/alarm-regeln.php) sind nicht gecached — sie zeigen sofort den korrekten Zustand.

„Schwerpunkt-Dispo"-Rolle lässt sich nicht speichern.

Deine Installation hat noch ein altes ENUM auf users.role aus dem Migrations-Skript 008_create_users.sql. Lösung: /admin/schema-check.php → „Reparieren" — die Spalte wird auf VARCHAR(32) migriert. Anschließend den User unter /admin/users.php einmal kurz bearbeiten und die Rolle nochmal auf „Schwerpunkt-Dispo" setzen.

Wichtigkeit „Bereitstellung" lässt sich nicht setzen.

Gleicher Mechanismus: alte ENUM auf einsaetze.wichtigkeit. /admin/schema-check.php → „Reparieren" — die Spalte wird auf VARCHAR(32) migriert + die Wichtigkeitsstufe bereitstellung wird geseedet.

Die DB hat einen anderen Präfix als die App erwartet.

Im .env-File ist DB_TABLE_PREFIX falsch gesetzt. Wert korrigieren und Browser-Reload — die App nutzt den neuen Präfix sofort.

Wenn Du die DB-Tabellen wirklich umbenennen willst (Migration auf neuen Präfix), gibt es ein SchemaProvider-Hilfsmittel — sprich uns an.

PDF-Export

PDF ist leer.

Wahrscheinlich werden die Anhänge gerade gerendert und der Browser hat zu früh abgebrochen. Reload (Strg+F5). Oder kleiner Filter setzen (kürzerer Zeitraum, weniger Einsätze).

PDF zeigt keine Bilder.

Sicher, dass die Anhänge auf der Platte noch existieren? Schau in storage/uploads/. Wenn die Datei weg ist (z. B. nach einem fehlgeschlagenen Restore), kann der PDF-Renderer sie nicht einbetten.

Lagekarte

Einsatzmarker stehen falsch.

Geocoding-Cache hat einen Treffer mit falschen Koordinaten. Auf /geocode-admin.php die Adresse suchen, löschen, beim nächsten Reload wird neu aufgelöst.

Wenn das Geocoding generell daneben liegt: geocode_suffix in /admin/config.php prüfen — passt der zu Deiner Region?

Heatmap zeigt nichts an.

Zu wenig Einsätze für eine sinnvolle Dichte. Oder im Wichtigkeits-Filter die Stufen abgehakt? Alle Häkchen setzen, dann wieder schauen.

Alarm-Regeln (UW-ERSTALARM)

/admin/alarm-regeln.php ist leer, nur ein „Wie funktioniert das?".

Die Default-Regel UW-ERSTALARM wurde nicht geseedet. Auf der Seite selbst gibt es einen gelben Hinweis-Block mit Button „Default UW-ERSTALARM-Regel anlegen" — klick den. Er legt automatisch fehlende Tabellen, die Wichtigkeit bereitstellung und die Regel + Followups an.

UW-ERSTALARM-Mail kommt rein, aber keine Folge-Einsätze entstehen.

Reihenfolge prüfen:

  1. /admin/alarm-regeln.php öffnen — ist die Regel da und auf „aktiv"?
  2. Stimmt das Trigger-Stichwort exakt mit dem Mail-Stichwort überein? (Case-insensitiv, aber sonst exakt.)
  3. Im Log-Dashboard unter Modul EINSATZ nach „Multi-Alarm-Regel ausgeloest" suchen — dort steht, ob die Regel gefeuert hat.
  4. Wenn ja, aber Folge-Einsätze fehlen: nach „Folge-Einsatz fehlgeschlagen"- Eintrag suchen. Häufige Ursache: die im Followup gewählte Wichtigkeit existiert nicht (Stammdaten checken).

Anzeige „Verarbeitete Alarme: 0" obwohl Einsätze rein kamen.

Die Anzeige im System-Status zeigt die Anzahl seit dem letzten ETB-Reset plus den 24-Stunden-Counter — beide aus der einsaetze-Tabelle. Zeigt sie dauerhaft 0, wurde entweder seither zurückgesetzt oder es liegen im 24-Stunden-Fenster keine Einsätze.

Die Leitstelle schickt keine Mail — kann ich den Alarm selbst anstoßen?

Ja. In der Einsatz-Übersicht gibt es den Knopf „Alarm auslösen": Er löst eine Folge-Einsatz-Alarmregel (z. B. UW-ERSTALARM) von Hand aus und legt — wie der echte Mail-Alarm — den Basis-Einsatz plus die Folge-Einsätze an der gewählten Adresse an und alarmiert per Telegram. Den Knopf siehst Du nur mit dem Recht „Alarm manuell auslösen" (Default Lage/Einsatzleiter/ Admin; eine geliehene Einsatz-Rolle zählt mit). Vollständige Anleitung unter Alarm-Regeln → Manuelle Auslösung.

„Diese Alarmregel wurde gerade ausgelöst. Bitte warte noch N Sekunden."

Das ist der Cooldown gegen versehentliche Doppelauslösung: Nach einer manuellen Auslösung ist dieselbe Regel 60 Sekunden gesperrt (und höchstens 10-mal pro Stunde auslösbar). Die Sperre hängt an der Regel, nicht am Benutzer — sie greift also auch, wenn jemand anderes gerade ausgelöst hat. Der automatische Mail-Alarm bleibt unberührt. Warte die angezeigte Restzeit ab oder nimm eine andere Regel.

Schwerpunkte

Einsatz landet nicht im Schwerpunkt.

  • Ist der Schwerpunkt im Status aktiv? pausiert schaltet die Auto-Zuweisung ab.
  • Ist der Schwerpunkt im Modus Orte? Im Modus Einsätze gibt es keine Auto-Zuweisung.
  • Passt der Ort des Einsatzes zu einem der Orte des Schwerpunkts? (Großschreibung egal, Aliase werden beachtet.)
  • Manuell zuweisen geht immer: ETB-Übersicht → Einsatz-Zeile → Symbol „Zuweisen".

Schwerpunkt lässt sich nicht erledigen.

Es gibt noch Einsätze im Schwerpunkt, die weder erledigt noch abgeschlossen sind — fürs Erledigen des Schwerpunkts reicht bei jedem Einsatz „mindestens erledigt". Auf der SP-Edit-Page siehst Du eine Liste; am schnellsten geht es im Schwerpunkttagebuch über „Einsätze abschließen". Falls ein Einsatz „Abschnitte in Arbeit" meldet: erst die Abschnitte erledigen (geht direkt im jeweiligen Dialog), dann den Einsatz.

Benutzer-Verwaltung

SP-Dispo auto-löschen geht nicht.

Es gibt aktuell kein Auto-Delete beim Schließen eines Schwerpunkts. Was es gibt: Setting sp_dispo_delete_on_reset (Default ja) — beim ETB-Reset (/admin/etb-reset.php) werden alle SP-Dispo-User mitgelöscht. Wenn Du einzelne SP-Dispos loswerden willst: in /admin/users.php auf „inaktiv" setzen — dann tauchen sie in den Dropdowns nicht mehr auf, bleiben aber für die Audit-Historie erhalten.

Ich kann keinen User löschen.

User mit zugewiesenen Einsätzen, Schwerpunkten oder Abschnitten können nicht gelöscht werden — wer hätte dann historisch die Mutation gemacht? Stattdessen: User deaktivieren (active = 0), dann taucht er in Dropdowns nicht mehr auf.

Anhänge

Gast kann mein PDF nicht herunterladen.

Per Default sperrt das ETB für Gäste den Download von Dokumenten (PDF, Audio, Office). Bilder gehen. Wenn Du dem Gast PDFs geben willst, gib seiner Rolle die Permission anhang.download_document.

„File too large".

PHP-Limits prüfen: upload_max_filesize und post_max_size in der php.ini. Default 2 MB ist für moderne Smartphone-Fotos viel zu wenig — setz auf mindestens 20 MB.

Performance

ETB ist langsam.

  • DB-Indizes komplett? /admin/schema-check.php zeigt fehlende Indizes an, „Jetzt anlegen" klicken.
  • Geocode-Cache aufgebläht? Auf /geocode-admin.php Größe prüfen und ggf. flushen.
  • storage/uploads/ voll? Alte Anhänge archivieren.

Wenn nichts hilft

  1. Logs lesen: /admin/log-dashboard.php zeigt alles — Cron-Log, Webhook-Log, Audit-Log.
  2. Webserver-Log: meist unter /var/log/apache2/error.log oder /var/log/nginx/error.log.
  3. PHP-Error-Log: pfad-abhängig, oft /var/log/php_errors.log.
  4. Issue auf GitHub: https://github.com/BrunSoftNet/ffw-einsatztagebuch/issues — mit Beschreibung was passiert ist, was Du erwartet hattest, und den relevanten Log-Auszügen.

Begriffe nachschlagen? → Glossar.