Files

T

clemens 9f2e1bdfb1 M3 Tenant-Aufloesung per App-Session ergaenzen

- Mandantenauswahl fuer Benutzer mit mehreren Tenants bauen
- feste Tenant-Domains ohne Wildcard-Abhaengigkeit vorbereiten
- Login, Backfill, Smoke-Checks und M3-Dokumentation aktualisieren

2026-07-13 20:04:20 +02:00

8.4 KiB

Raw Blame History

M3 SaaS-Basis Vorbereitung

Stand: 2026-07-12

M3 fuehrt Mandanten, Benutzer, Mitgliedschaften und Grundeinstellungen additiv ein. Die bestehende Legacy-App bleibt dabei lauffaehig und wird noch nicht auf das neue Modell umgestellt.

Ziel

Einen Default-Tenant fuer den aktuellen Bestand erzeugen.
Login-Benutzer und Kaffee-Teilnehmer fachlich trennen.
Rollen tenant-spezifisch vorbereiten.
Bestehende kl_Mitarbeiter ohne Datenverlust in participants spiegeln.
Die Grundlage fuer Registrierung und Login schaffen, ohne die Legacy-Auth sofort zu ersetzen.

Nicht-Ziele fuer den ersten M3-Schritt

Kein kompletter Login-Umbau in einem Schritt.
Keine Migration von Einzahlungen und Kaffeeverbrauch nach ledger_entries; das gehoert zu M4.
Kein Design- oder Layout-Umbau.
Kein Billing und keine Tarife im ersten Schritt.
Kein produktiver Tenant-Wechsel in bestehenden Legacy-Seiten.

Umgesetzter erster Schritt

Umgesetzte Migrationen:

database/migrations/0002_saas_identity_tenants.sql
database/migrations/0003_saas_auth_account_fields.sql
database/migrations/0004_saas_auth_tokens.sql
database/migrations/0005_saas_tenant_resolution.sql

Tabellen:

tenants
tenant_settings
users
tenant_memberships
participants
tenant_domains

Ergaenzende Skripte:

scripts/backfill-default-tenant.php
scripts/check-m3-saas-basis.php
scripts/check-m3-auth-flow.php
scripts/check-m3-settings-flow.php
scripts/check-m3-password-email-flow.php
scripts/check-m3-tenant-resolution-flow.php

Wichtige Regeln:

users sind Login-Konten.
participants sind Kaffeelisten-Teilnehmer.
Ein participant kann optional auf einen user zeigen.
Rollen liegen in tenant_memberships, nicht in participants.
participants.legacy_mitarbeiter_id speichert die alte ID aus kl_Mitarbeiter.
Geldwerte in neuen Settings als Cent-Integer speichern.
Die Migration ist rein additiv; bestehende Legacy-Seiten fragen weiter die bisherigen kl_*-Tabellen ab.

Default-Tenant

Fuer den Bestand wird ein erster Tenant angelegt:

slug: default
name: Kaffeeliste Bestand
status: active
timezone: Europe/Berlin
locale: de-DE
currency_code: EUR

Die Werte koennen spaeter in einer Tenant-Einstellungsseite angepasst werden.

Backfill

Ein separates Skript spiegelt die bestehenden Mitarbeiter:

scripts/backfill-default-tenant.php

Vorgang:

Default-Tenant anlegen oder laden.
tenant_settings aus kl_config erzeugen.
Fuer jede Zeile aus kl_Mitarbeiter einen participant anlegen oder aktualisieren.
Fuer aktive Admins optional einen user und eine tenant_membership erzeugen.
admin = 1 als Rolle admin abbilden; ein konfigurierter erster Benutzer kann Rolle owner erhalten.
Verwaiste participants mit nicht mehr vorhandener legacy_mitarbeiter_id aus dem Default-Tenant entfernen.

Der Backfill muss idempotent sein und darf keine bestehenden Legacy-Daten loeschen. Geloescht werden nur SaaS-Spiegelungen, deren Legacy-Mitarbeiter in kl_Mitarbeiter nicht mehr existiert.

Ausgefuehrter Dev-Stand:

Default-Tenant default wurde angelegt.
9 Legacy-Mitarbeiter wurden als participants gespiegelt.
2 aktive Admin-/Owner-Logins wurden als users und tenant_memberships angelegt.
Ein zweiter Backfill-Lauf blieb idempotent.

Umgesetzte Dateien:

app/database.php
app/saas-auth.php
login.php
register.php
konto.php
logout.php
mandant-auswahl.php
passwort-vergessen.php
passwort-zuruecksetzen.php
email-verifikation-senden.php
email-verifizieren.php

Umgesetzter Umfang:

Registrierung legt Tenant, Owner-User, Default-Settings, Membership und Owner-Participant in einer Transaktion an.
Login prueft users.password_hash, aktive Membership und aktiven Tenant.
Hat ein User genau einen aktiven Mandanten, wird dieser direkt in die Session gelegt.
Hat ein User mehrere aktive Mandanten, fuehrt der Login zur Mandantenauswahl.
Logout beendet die neue PHP-Login-Session.
konto.php zeigt den aktuellen SaaS-Kontext fuer den angemeldeten User.
functions.php akzeptiert eine SaaS-Login-Session als erste Identitaetsquelle, laesst DEV_AUTH_EMAIL und AUTH_USER aber als Legacy-Fallback bestehen.
footer.php ist fuer nicht angemeldete Public-Seiten sicher und zeigt Links zu Login und Registrierung.
Passwort-Reset erzeugt Single-Use-Tokens und speichert nur Token-Hashes.
E-Mail-Verifikation erzeugt Single-Use-Tokens und setzt users.email_verified_at.
Bis zum produktiven Mailversand werden Links nur im Dev-Modus angezeigt beziehungsweise in CLI-Checks direkt verwendet.

Noch offen im M3-Auth-Scope:

Weitergehende Rollenmatrix fuer spaetere SaaS-Seiten.
Produktiver Mailversand fuer Reset- und Verifikationslinks.

Tenant-Aufloesung

Entscheidung fuer den Webspace-Betrieb:

Keine Wildcard-Subdomains im ersten Schritt.
Primaere App-Adresse ist eine zentrale App-Domain wie app.kaffeeliste.de.
Der aktive Mandant wird nach Login ueber tenant_memberships und die PHP- Session gesetzt.
Bei genau einem Mandanten wird automatisch weitergeleitet.
Bei mehreren Mandanten nutzt der User mandant-auswahl.php.
tenant_domains ist vorbereitet fuer spaeter gezielt eingerichtete feste Domains oder Subdomains, aber nicht Voraussetzung fuer den Start.

Noch offen:

APP_PRIMARY_HOST in der Zielumgebung setzen.
Produktive Domain-/Zertifikatspruefung fuer einzelne feste Domains definieren.

Rollen und Grundeinstellungen