evoyo.la
Gutz Admin
Zentrales Filament-5-Admin, das die Adminflächen von Gutz Intern und der Vereinswebsite über eine Multi-Datenbank-Architektur zusammenführt.
Vor Gutz Admin gab es zwei getrennte Admin-Oberflächen — eine in Gutz Intern (Filament 5, für Mitglieder, Schichten, Finanzen), eine in der Vereinswebsite (Filament 3, für Inhalte, Events, Galerie). Das führte zu doppelter Pflege, uneinheitlichen Rechtekonzepten und fehlender Gesamtsicht. Gutz Admin ist ein einziges Filament-5-Panel, das lesend und schreibend über drei getrennte, produktiv unabhängige Datenbanken arbeitet.
Case Study
Ausgangslage
Ein In-Place-Umbau eines der bestehenden Projekte wurde verworfen, weil beide unterschiedliche Filament-Versionen (3 und 5) und unterschiedliche, verstreute Rechteprüfungen hatten. Stattdessen entstand Gutz Admin als komplett neues Projekt.
Herausforderung
Ein einziges Panel muss lesend und schreibend auf drei getrennte MySQL-Datenbanken zugreifen (die neue Integrations-DB sowie die produktiven Datenbanken von Gutz Intern und der Vereinswebsite). Jedes Eloquent-Model bekommt seine Datenbankverbindung explizit gesetzt. Eine zweite, damit verknüpfte Herausforderung ist die Authentifizierung: Der Login läuft weiterhin gegen die Nutzerdaten von Gutz Intern, Filament braucht aber einen lokalen Nutzerdatensatz für Rollen und Berechtigungen — gelöst über einen „Schattenuser“, der bei jedem Login gespiegelt und zusätzlich per Command batchweise synchronisiert wird, mit eigener Lauf-Protokollierung.
Vorgehen
Laravel 13, Filament 5, PHP 8.3, als komplett neues Projekt aufgesetzt statt eines Forks. Zusätzliche Pakete für PDF-Export, Bildbearbeitung, Barcode-Generierung und Sentry-Monitoring.
Entscheidungen
Die Fachbereiche bleiben in ihrer jeweils führenden Datenquelle, um unnötige Datenduplizierung zu vermeiden; nur Governance-Daten (Rollen, Modulzugriffe, Sync-Status, Audit-Logs) leben in der neuen Admin-Datenbank.
Login läuft weiter gegen die bestehenden Nutzerdaten; ein Sync spiegelt sie bei jedem Login sowie batchweise per Command in die lokale Admin-Datenbank, mit Protokollierung fehlgeschlagener Läufe.
Feingranulare Rechte statt weniger großer Verwaltungsrechte, mit Alias-Mapping alter Rollen-Slugs, damit bestehende Zuweisungen ohne manuelle Nacharbeit übernommen werden.
Die alten Panels bleiben parallel bestehen, Module werden schrittweise migriert und ihr Fortschritt über eine eigene Audit-Seite messbar gemacht.
Die Hauptnavigation gliedert sich nach Aufgabenbereich (Mitglieder, Schichten, Finanzen, Inhalte, Medien); Filament-Resources dienen nur noch der Detailpflege.
Eigenanteil
61 Eloquent-Models, 33 Filament-Resources, 26 Pages, mehrere Dashboard-Widgets, der Sync-Command für die Nutzerspiegelung, der Auth-Service für den Cross-Datenbank-Login sowie die zentrale Rechte- und Navigationslogik — alles solo umgesetzt.
Ergebnisse