clemensandClaude Sonnet 5
cbe6547f3a
Neue, bewusst von tenant_memberships/saas_user_has_role() komplett getrennte Platform-Admin-Ebene (neue Tabelle platform_admins), damit die bestehende, automatisiert getestete Mandanten-Isolation (check-m8-tenant-isolation.php, check-m8-role-matrix.php) unangetastet bleibt - Platform-Admin-Rechte wirken ausschliesslich auf den neuen backoffice-*.php-Seiten. - backoffice.php: Uebersicht aller Mandanten (Status, Teilnehmerzahl, Saldensumme). - backoffice-mandant.php: reine Leseansicht eines Mandanten (Einstellungen, Mitglieder/Rollen, letzte Buchungen, letzte Admin-Aktionen). Bewusst kein Schreibzugriff von hier aus. - backoffice-export.php: nutzt dieselbe app_export_tenant_data() wie der Selbstbedienungs-Export, ausgeloest durch den Platform-Admin fuer beliebige Mandanten. - scripts/grant-platform-admin.php: CLI-only Bootstrap fuer den ersten Platform-Admin, bewusst keine Web-UI dafuer. - Jede Back-Office-Ansicht/-Export wird im Audit-Log DES BETROFFENEN MANDANTEN protokolliert (Transparenzpflicht), nicht nur beim Betreiber. Der bestehende Selbstbedienungs-Export (datenexport.php aus M8) bleibt zusaetzlich bestehen statt ersetzt zu werden: der Mandant ist im AV- Verhaeltnis Verantwortlicher, Art. 15/20/28 DSGVO verpflichten den Auftragsverarbeiter zur Unterstuetzung bei Ausk''unfts-/Portabilitaets- rechten - ein jederzeit verfuegbarer Mandanten-Export erfuellt das direkt. Details und Begruendung in docs/backoffice.md. Live getestet: Back-Office zeigt alle Mandanten korrekt (inkl. echter Bestandsmandanten), Detail/Export fuer Test-Mandant funktioniert, Audit-Log korrekt geschrieben. Kritischer Test bestanden: derselbe Platform-Admin sieht auf normalen Mandanten-Seiten weiterhin nur seinen eigenen Mandanten; ein eingeloggter Nicht-Platform-Admin bekommt 403. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kaffeeliste
Dieses Repository enthält den laufenden Umbau der Kaffeelisten-App von einer Windows/IIS/LDAP-gebundenen Legacy-App zu einer mehrkundenfähigen SaaS- Anwendung. Der Umbau erfolgt schrittweise im selben Repository, nicht in einem getrennten Zielverzeichnis: Legacy-Seiten und neue SaaS-Bausteine liegen nebeneinander, bis eine Seite vollständig auf das neue Modell umgestellt ist.
Den vollständigen Plan mit Zielbild, Datenmodell, Rollenmodell und
Meilensteinen beschreibt docs/saas-umstrukturierungsplan.md. Der
Fortschritt je Meilenstein steht in docs/m2-technical-foundation.md bis
docs/m5-app-kern.md.
Struktur
- Legacy- und SaaS-Seiten liegen als flache PHP-Dateien im Webroot, zum
Beispiel
index.php,stricheintragen.php,kaffeeliste.php,mitarbeiterverwalten.php. app/: zentrale Bausteine für Bootstrap, DB-Zugriff, Auth, Mail und das neue Ledger-Modell (app/ledger.php).database/migrations/: versionierte Schemaänderungen, anzuwenden überscripts/migrate.php.scripts/: Migrations-, Backfill- und Prüfskripte (Golden Master, HTTP-Smoke, M3/M4-Checks).docs/: Planungs- und Meilensteindokumentation.
Umgang mit Legacy-Seiten
- Seiten, die noch direkt auf
kl_*-Tabellen schreiben, werden schrittweise auf tenant-sicheres Lesen/Schreiben überapp/ledger.phpundapp/saas-auth.phpumgestellt; siehe die Meilensteindokumente für den aktuellen Stand je Seite. - Neue Produktfunktionen entstehen gegen das neue Modell (Tenants, Users,
Participants, Ledger), nicht mehr direkt gegen die
kl_*-Tabellen. - Lokale Entwicklung gegen MySQL ist in
docs/dev-mysql.mdbeschrieben.