Admin · Aktionen

Schema-Check

Diese Seite (Admin → Aktionen → „Schema-Check") vergleicht das im Code definierte Datenbank-Schema mit dem tatsächlichen Stand Deiner Datenbank und repariert Abweichungen auf Knopfdruck. Du brauchst sie vor allem nach einem Code-Update, das neue Tabellen, Spalten oder Default-Daten mitbringt.

ℹ️ Wenn etwas am Schema fehlt, warnt das ETB von selbst über den Schema-Banner in der Sidebar — der Admin sieht dort den Direkt-Link hierher. Der Banner erscheint direkt nach dem Anmelden; früher konnte er bis zu einer Stunde ausbleiben, weil der Prüfstand in der Sitzung zwischengespeichert war.

ℹ️ Zusätzlich meldet sich der Schema-Check von selbst. Findet er offene Reparaturen, schickt er höchstens einmal am Tag eine Meldung an die Administration (Meldungsart „Schema-Check meldet fehlende Tabellen", siehe Meldungen). Hintergrund: Nach dem 4.6-Release blieb der Check unbemerkt liegen, und die Bevölkerungswarnung arbeitete stillschweigend nicht.

Was die Seite zeigt

Oben steht eine Status-Zeile mit vier Zahlen: Tabellen vorhanden, Tabellen fehlen, Spalten veraltet und Tabellen im Code definiert. Darunter erscheinen je nach Befund eigene Karten:

  • Veraltete Spalten-Definitionen — eine Spalte in der DB stimmt nicht mehr mit dem Code überein. Typischer Fall: eine ENUM-Spalte (z. B. users.role), die einen neuen Wert noch nicht kennt, sodass das Feld beim Speichern leer bleibt.
  • Fehlende Tabellen — Tabellen, die der Code erwartet, aber in der DB noch nicht existieren.
  • Schema vollständig — alles da; hier kannst Du trotzdem die Indizes nochmal prüfen lassen (idempotent, legt nichts Neues an).

Ganz unten listet die Seite alle Tabellen des Code-Schemas auf — vorhandene unauffällig, fehlende hervorgehoben.

Reparieren

Je nach Befund steht ein Button bereit („Fehlende Tabellen jetzt anlegen", „Spalten jetzt migrieren" oder „Indizes nochmal prüfen"). Nach der Bestätigung erledigt der Schema-Check alles Nötige in einem Rutsch:

  1. fehlende Tabellen anlegen (CREATE TABLE IF NOT EXISTS — bestehende bleiben unangetastet; z. B. die Rollen-Angebote des Alarm-Knopfs),
  2. fehlende Indizes nachziehen,
  3. veraltete Spalten migrieren (z. B. ENUM erweitern),
  4. fehlende Default-Daten ergänzen (z. B. Status-Stufen, Rollen-Rechte, die UW-ERSTALARM-Regel, den Meldungskatalog samt Regeln und die Rolle Einsatzkraft),
  5. einmalige Daten-Korrekturen ausführen — z. B. alte Einsatzkräfte-Stärkewerte auf das Schema A/B/C/S normalisieren (damit die Gesamtzahl überall zur Summe der drei Positionen passt), die Suffix-Spalten für das Adress-Suffix je Ort anlegen oder die Schwerpunkt-Status-Labels von „Geschlossen"/„Archiviert" auf „Erledigt"/„Abgeschlossen" umbenennen (nur unveränderte Werks-Labels; selbst angepasste bleiben unberührt).

Eine Erfolgsmeldung fasst zusammen, was angelegt, ergänzt oder migriert wurde; eigene Karten listen die Details.

⚠️ Hatte ein Benutzer durch eine veraltete ENUM-Spalte eine leere Rolle bekommen (sah aus wie „nicht übernommen"), repariert die Spalten-Migration das nicht automatisch — die Rolle danach unter Admin → Benutzer nachpflegen.

ℹ️ Reparieren darf nur, wer das Recht admin.config hat. Bestehende Daten bleiben bei allen Schritten erhalten.

ℹ️ Nach dem Update auf den Meldungs-Bus legt der Schema-Check acht neue Tabellen an: sechs für den Bus (Zuordnung Benutzer ↔ Löschgruppe, Meldungskatalog, Regeln, Meldungen, Zustellprotokoll und die Chat-Zuordnung) und zwei für Web Push (push_abos für die eingerichteten Geräte, push_einladungen für die Einladungslinks). Dazu spielt er den Meldungskatalog samt Startvorlagen ein, ergänzt die Rolle Einsatzkraft und trägt das neue Recht „Nachricht verschicken" für alle Rollen nach, die schon „Alarm manuell auslösen" haben. Bestehende Einstellungen fasst er dabei nicht an — ein bereits angepasster Katalog bleibt, wie er ist. Details: Meldungen, Web Push und Permission-Matrix.

⚠️ Nach dem Update auf Postfach und Profil ergänzt der Lauf zwei Spalten an den Geräten (push_abos.freigegeben_at für die Freigabe, push_abos.letzter_empfang für den Empfangsnachweis), trägt das Recht „Rückmeldungen anderer sehen" (mitteilung.rueckmeldungen) für alle Rollen nach, die schon „Nachricht verschicken" haben, und markiert einmalig alle bereits angemeldeten Geräte als freigegeben.

Der letzte Schritt läuft genau einmal und merkt sich das: Er soll die Wehr nach dem Update nicht stumm stehen lassen, aber auch keine Anfrage überfahren, die ein Administrator bewusst liegen lässt.

Solange der Lauf fehlt, stellt das ETB weiter an alle Geräte zu (ein ausdrücklicher Rückfall — eine unalarmierte Wehr wäre das größere Übel), die Freigabe wirkt aber nicht und die Bereitschaftsanzeige unter Web Push bleibt leer. Im Log steht dann „Freigabe-Spalte fehlt — Schema-Check fällig".

⚠️ Für die Erprobung des Zustellwegs kommt eine Spalte an den Benutzern dazu — users.meldung_kanal. Sie hält den Zustellweg je Person („Standard", „Telegram und Web Push", „Nur Telegram", „Nur Web Push"); leer bedeutet Standard, also der Weg der Wehr. Bestandsdaten brauchen keine Umstellung: Leer ist genau das bisherige Verhalten, und gelesen wird die Spalte ohnehin nur, solange eine Erprobung läuft.

Solange der Lauf fehlt, ändert sich nichts — es gilt der Zustellweg der Wehr für alle, und die Ausnahmeliste bleibt leer. Setzt Du unter Benutzer trotzdem eine Zustellung, meldet die Seite „User gespeichert, aber der Zustellweg nicht — führe /admin/schema-check.php aus." Das ist Absicht: Ein still verworfener Wert hätte Dich eine Erprobung für scharf halten lassen, die gar nicht läuft. Details: Meldungen → „Erprobung".

ℹ️ Zwei Schritte richten den Meldungs-Katalog nach. Der erste trägt fehlende Kurz- und Langfassungen in Regeln nach, deren Textfeld leer geblieben war — sonst zeigt die Benachrichtigung auf dem Sperrbildschirm nur den Betreff. Er fasst ausschließlich leere Felder an, gibt einer bereits angepassten Fassung derselben Meldungsart den Vorrang vor dem Standardtext und läuft genau einmal: Eine bewusst geleerte Kurzfassung bekommst Du nicht beim nächsten Durchgang zurück.

Der zweite stellt die Antworten „Freigeben"/„Abmelden" an „Neues Gerät angemeldet" wieder her. Diese Werte gehören dem Programm — ein Tipp darauf gibt ein Gerät wirklich frei —, deshalb prüft der Schritt sie bei jedem Lauf. Fehlen sie, stünde die Geräte-Freigabe im Postfach ohne Knopf da. Details: Meldungen.

⚠️ Nach dem Update auf die vollständig netzunabhängige Atemschutzüberwachung kommt eine Spalte dazu: atemschutz_ue.uebergabe_an_geraet. Sie hält die Kennung des Geräts, das eine Übergabe angefragt hat — über den Tablet-Zugang gibt es kein Konto, dort ist das Gerät die einzige Kennung.

Solange der Lauf fehlt, fällt genau eine Sache aus: das Übergeben. Eine Anfrage an einen Tablet-Zugang lässt sich gar nicht erst stellen, und eine offene Anfrage nicht bestätigen. Übernehmen, Ablehnen und Abschließen laufen weiter — das ist ausdrücklich so gebaut, damit eine laufende Überwachung an einer fehlenden Spalte nicht hängen bleibt.

⚠️ Und eine zweite Spalte für die Einsatz-Zeitleiste: einsatz_kommentar.eingang_at hält fest, wann eine Meldung wirklich ankam — die bisherige Zeitangabe trägt bei einem Nachtrag die Ereigniszeit, und die kommt über den Tafel-Zugang aus einem Formularfeld.

Solange der Lauf fehlt, fällt nichts aus — aber es schützt auch nichts. Die Mengenbegrenzung zählt dann nichts und greift nie. Die Tafel schreibt weiter wie bisher, und die Seite Atemschutz verwalten sagt Dir, dass die Begrenzung noch nicht messen kann.

Wenn ein Schritt fehlschlägt

Die Reparatur bricht bei einem Fehler nicht ab — sie macht weiter und merkt sich die Stelle. Steht danach „Reparatur unvollständig" in Gelb, dann sind einzelne Schritte nicht durchgelaufen; welche, steht in der Liste darunter mit ERROR davor.

Ruf den Knopf dann einfach ein zweites Mal auf. Manche Schritte bauen aufeinander auf, und der zweite Lauf findet vor, was der erste angelegt hat. Bleibt es auch danach dabei, melde Dich — dann steckt mehr dahinter.

Was als nächstes?