Zwei getrennte Flows:
- Teilnehmer anonymisieren statt loeschen (ledger_anonymize_participant):
Name/E-Mail/PayPal-Name werden durch einen Platzhalter ersetzt, das
Mitglied deaktiviert und vom Login-Konto getrennt. Buchungshistorie
bleibt fuer die Kassenfuehrung erhalten, konsistent mit dem
Storno-statt-Delete-Prinzip. Default-Mandant spiegelt die
Anonymisierung in kl_Mitarbeiter (Email dort NOT NULL UNIQUE, bekommt
Platzhalter statt NULL). Inhaber kann nicht anonymisiert werden.
- Mandant vollstaendig loeschen (mandant-loeschen.php, nur Inhaber):
erfordert exakte Eingabe des Kundenkuerzels, loescht die tenants-Zeile;
alle tenant-scoped Tabellen kaskadieren per Fremdschluessel. users
bleiben bestehen (koennen zu mehreren Mandanten gehoeren). Der
migrierte Default-Mandant ist ausgenommen, da seine kl_Mitarbeiter-
Historie sonst verwaisen wuerde.
Live getestet: Mitglied mit Buchungshistorie anonymisiert (Historie
blieb erhalten), Mandantenloeschung mit falscher/richtiger Bestaetigung
geprueft, vollstaendiger Cascade-Delete ueber alle tenant-scoped Tabellen
verifiziert, globale users-Zeile bleibt korrekt erhalten.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neue Seite datenexport.php (Owner/Admin) laedt einen vollstaendigen
JSON-Export des eigenen Mandanten herunter: Stammdaten, Einstellungen,
Teilnehmer, Mitglieder mit Rolle, alle Ledger-Buchungen, Hinweise,
CSV-Importe, Mail-Versandlog und Admin-Protokoll. Passwort- und
Token-Hashes werden bewusst nicht exportiert; der Export selbst wird im
Audit-Log protokolliert. Link von konto.php aus.
Live getestet: eigens angelegter Test-Mandant, Export heruntergeladen,
Header und JSON-Struktur geprueft, keine Passwoerter im Export gefunden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Auth-Token-Tabelle mit gehashten Single-Use-Tokens einführen
- Passwort-Reset und E-Mail-Verifikation als Dev-Flow bauen
- Token-Flow-Test, Smoke-Abdeckung und M3-Dokumentation aktualisieren
clemensandClaude Sonnet 5