From 8511b876f3d02f4fa9c5e1276861f0b904b0d450 Mon Sep 17 00:00:00 2001 From: Clemens Creutzburg Date: Sun, 12 Jul 2026 17:50:16 +0200 Subject: [PATCH] =?UTF-8?q?M2=20abschlie=C3=9Fen=20und=20M3=20vorbereiten?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - M2-Abschlussstatus und Abschlusskriterien dokumentieren - M3-SaaS-Basisplan mit Tenant/User/Participant-Modell ergänzen - Hauptplan mit M2-Abschluss und M3-Startpunkten aktualisieren --- docs/m2-technical-foundation.md | 39 ++++++++-- docs/m3-saas-basis-vorbereitung.md | 118 +++++++++++++++++++++++++++++ docs/saas-umstrukturierungsplan.md | 9 ++- 3 files changed, 157 insertions(+), 9 deletions(-) create mode 100644 docs/m3-saas-basis-vorbereitung.md diff --git a/docs/m2-technical-foundation.md b/docs/m2-technical-foundation.md index 8167950..967e1cb 100644 --- a/docs/m2-technical-foundation.md +++ b/docs/m2-technical-foundation.md @@ -5,6 +5,9 @@ Stand: 2026-07-12 M2 fuehrt die technischen Grundbausteine fuer den SaaS-Umbau ein, ohne das Legacy-Verhalten oder das bestehende Design zu veraendern. +Status: abgeschlossen fuer den M2-Scope. Bewusst ausgelagerte Themen sind unten +als Grenzen und M3-/M6-Uebergabe dokumentiert. + ## Ziel - Versionierte Datenbankmigrationen statt loser Schema-Ausfuehrung. @@ -142,13 +145,35 @@ Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`, ## Bewusste Grenzen - Keine Tenant-/User-/Rollen-Tabellen in M2. Diese gehoeren zu M3. -- Keine globale CSRF-Erzwingung in M2. Die Absicherung weiterer POST-Seiten - erfolgt schrittweise. -- Kein Layout-Umbau in M2. Die visuelle Struktur bleibt stabil. +- Keine globale CSRF-Erzwingung fuer Spezialprozesse. `mailversenden.php` und + `jahresauswertung.php` werden in M6 als Jobs mit Dry-Run, Audit und + Versandlog neu betrachtet. +- Kein Layout-Umbau in M2. Die visuelle Struktur bleibt stabil; Public-/App- + Layouts werden mit der M3-/M7-Struktur vorbereitet. - PDF-/Mail-/Jahresprozesse bleiben als M6-Themen offen. -## Naechste Schritte +## Abschlusskriterien -1. Eine duenne View-/Layout-Struktur vorbereiten, ohne Header/Footer-Markup - sofort zu verschieben. -2. Danach M3 starten: Tenants, User, Registrierung, Login und Rollen. +- Migrationsrunner ist vorhanden und idempotent. +- Bootstrap, Session und CSRF-Helper sind zentral verfuegbar. +- Die relevanten Legacy-Schreibseiten sind CSRF-geschuetzt. +- CSV-Uploads liegen nicht mehr im Webroot. +- Bestehende Legacy-Seiten bleiben per HTTP-Smoke erreichbar. +- Golden-Master-Fachwerte bleiben unveraendert. + +## Uebergabe an M3 + +M3 startet mit additiven SaaS-Tabellen und einer Default-Tenant-Abbildung. Die +Legacy-Seiten sollen dabei weiterhin ueber die bestehenden Tabellen laufen, bis +der fachliche Kern in M4/M5 schrittweise auf das Zielmodell umgestellt wird. + +Naechster Startpunkt: + +1. `tenants`, `tenant_settings`, `users`, `tenant_memberships` und + `participants` als neue Migration anlegen. +2. Einen Default-Tenant fuer die bestehende Kaffeeliste definieren. +3. Bestehende `kl_Mitarbeiter` in `participants` spiegeln, inklusive + `legacy_mitarbeiter_id`. +4. Admins aus `kl_Mitarbeiter.admin` als `tenant_memberships.role = 'admin'` + beziehungsweise fuer den ersten Hauptnutzer als `owner` abbilden. +5. Erst danach Login/Registrierung und Public-/App-Routen anschliessen. diff --git a/docs/m3-saas-basis-vorbereitung.md b/docs/m3-saas-basis-vorbereitung.md new file mode 100644 index 0000000..1780501 --- /dev/null +++ b/docs/m3-saas-basis-vorbereitung.md @@ -0,0 +1,118 @@ +# 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, keine Tarife, keine E-Mail-Verifikation im ersten Schritt. +- Kein produktiver Tenant-Wechsel in bestehenden Legacy-Seiten. + +## Vorgeschlagene Migration + +Naechste Migration: + +```text +database/migrations/0002_saas_identity_tenants.sql +``` + +Tabellen: + +- `tenants` +- `tenant_settings` +- `users` +- `tenant_memberships` +- `participants` + +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. + +## Default-Tenant + +Fuer den Bestand wird ein erster Tenant angelegt: + +```text +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-Vorschlag + +Ein separates Skript sollte die bestehenden Mitarbeiter spiegeln: + +```text +scripts/backfill-default-tenant.php +``` + +Vorgang: + +1. Default-Tenant anlegen oder laden. +2. `tenant_settings` aus `kl_config` erzeugen. +3. Fuer jede Zeile aus `kl_Mitarbeiter` einen `participant` anlegen oder + aktualisieren. +4. Fuer aktive Admins optional einen `user` und eine `tenant_membership` + erzeugen. +5. `admin = 1` als Rolle `admin` abbilden; ein konfigurierter erster Benutzer + kann Rolle `owner` erhalten. + +Der Backfill muss idempotent sein und darf keine bestehenden Legacy-Daten +loeschen. + +## Erste Akzeptanzkriterien + +- Migrationen laufen mehrfach ohne Fehler. +- Default-Tenant existiert genau einmal. +- `tenant_settings` enthalten Preis pro Strich und bestehende PayPal-Optionen. +- Jeder bestehende `kl_Mitarbeiter` hat genau einen `participant`. +- `participants.legacy_mitarbeiter_id` ist gesetzt. +- Admins werden als tenant-scoped Rolle abgebildet. +- Golden-Master und HTTP-Smoke bleiben gruen. + +## Risiken + +| Risiko | Gegenmassnahme | +| --- | --- | +| Login-User und Kaffee-Teilnehmer werden vermischt | `users` und `participants` strikt getrennt halten | +| Mehrfacher Backfill erzeugt Duplikate | Eindeutige Constraints und Upsert-Logik | +| Legacy-App bricht durch neue Tabellen | M3 nur additiv, keine Legacy-Queries umstellen | +| Rollen werden global statt tenant-scoped | Rollen ausschliesslich in `tenant_memberships` speichern | +| Falsche Owner-Zuordnung | Owner per Env-Konfiguration oder manuell dokumentierter Entscheidung setzen | + +## Empfohlene Reihenfolge + +1. Migration `0002_saas_identity_tenants.sql` erstellen. +2. `scripts/backfill-default-tenant.php` erstellen. +3. Backfill gegen die Dev-Datenbank ausfuehren. +4. Kontrollskript fuer Tenant/Participant/Role-Counts schreiben. +5. Golden-Master und HTTP-Smoke ausfuehren. +6. Danach Login-/Registrierungsrouten planen. + diff --git a/docs/saas-umstrukturierungsplan.md b/docs/saas-umstrukturierungsplan.md index ce7fed9..613d998 100644 --- a/docs/saas-umstrukturierungsplan.md +++ b/docs/saas-umstrukturierungsplan.md @@ -282,7 +282,7 @@ Uebersicht: | --- | --- | --- | | M0 | Baseline | Bestand, Sicherheit und Designreferenz sind dokumentiert | | M1 | Golden Master | Legacy-Ergebnisse sind als Vergleichsbasis eingefroren; HTTP-Smoke prueft sichere Seiten | -| M2 | Technisches Fundament | Migrationen, Bootstrap, Session und CSRF-Helper stehen | +| M2 | Technisches Fundament | Abgeschlossen: Migrationen, Bootstrap, Session, CSRF-Helper und Legacy-Schreibseitenschutz stehen | | M3 | SaaS-Basis | Tenants, User, Registrierung, Login und Rollen funktionieren | | M4 | Datenmigration | Legacy-Daten sind tenant-sicher im Zielmodell abgebildet | | M5 | App-Kern | Dashboard, Striche, Einzahlungen, Mitglieder und Liste laufen | @@ -395,6 +395,7 @@ Ergebnis: - Grundgeruest fuer neue SaaS-App. - Kein fachlicher Rewrite, aber klare Struktur fuer die Migration. - Dokumentation: `docs/m2-technical-foundation.md`. +- Status: abgeschlossen fuer den M2-Scope. Abhaengigkeiten: @@ -409,7 +410,11 @@ Mehrkundenfaehigkeit und Kunden-Onboarding technisch aktivieren. Schritte: - Tabellen fuer `tenants`, `users`, `tenant_memberships` und - `tenant_settings` anlegen. + `tenant_settings` anlegen. Vorbereitung dokumentiert in + `docs/m3-saas-basis-vorbereitung.md`. +- Zusaetzlich `participants` als getrennte Kaffee-Teilnehmer-Tabelle anlegen. +- Default-Tenant fuer den aktuellen Bestand anlegen. +- Bestehende `kl_Mitarbeiter` idempotent in `participants` spiegeln. - Registrierung: Tenant + Owner-User + Default-Settings erzeugen. - Login, Logout, Passwort-Reset und E-Mail-Verifikation bauen. - Tenant-Aufloesung definieren.