faq.php zeigte bislang fuer jeden Mandanten denselben, komplett
AOK-spezifischen Inhalt (Kaffeemaschinen-Bedienung, interner
Ansprechpartner) - fuer andere Kunden unbrauchbar und inhaltlich falsch.
- Neue Tabelle faq_entries (tenant-scoped, Soft-Delete, sort_order).
- Migration uebernimmt die bisherigen AOK-Inhalte einmalig als FAQ des
migrierten Default-Mandanten; andere Mandanten sehen sie nicht.
- Neue Mandanten bekommen bei der Registrierung automatisch eine kurze
generische Starter-FAQ (faq_seed_default_entries), frei editierbar.
- faq.php: lesbar fuer alle angemeldeten Mitglieder eines Mandanten,
Anlegen/Bearbeiten/Entfernen auf owner/admin beschraenkt.
- Landingpage verweist nicht mehr auf faq.php (jetzt interner,
mandantengebundener Inhalt statt oeffentlicher Marketing-Seite).
Live getestet: AOK-Carry-over fuer Default-Mandant, frisch registrierter
Test-Mandant bekam isolierte generische Starter-FAQ, Anlegen mit
HTML-Payload (korrekt escaped), Bearbeiten und Soft-Delete geprueft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
stricheintragen.php und einzahlung.php lasen ihren Mitarbeiter-Picker
bisher direkt aus der global unscoped kl_Mitarbeiter-Tabelle. Fuer jeden
Mandanten ausser dem Default-Mandanten zeigte das fremde Namen und
Schreiben schlug (sicher, aber unverstaendlich) am Tenant-Check in
ledger_mirror_legacy_* fehl.
- Picker kommt jetzt aus participants (tenant-scoped), Formularfelder
nutzen participant_id statt MitarbeiterID.
- Schreibpfad pro Teilnehmer: mit legacy_mitarbeiter_id (Default-Mandant)
weiterhin Dual-Write nach kl_Kaffeeverbrauch/kl_Einzahlungen plus
Ledger-Spiegelung; ohne Legacy-Verknuepfung (jeder andere Mandant) direkt
ueber neue ledger_record_consumption()/ledger_record_payment().
- Vorderseite/Rueckseite-Filter (100-Tage-Regel) bleiben fuer den
Default-Mandanten exakt auf der bisherigen Legacy-Logik; andere
Mandanten nutzen die neue ledger_fetch_participants_by_window_marks()
mit tenant_settings.sheet_window_days.
- Nebenbei behoben: einzahlung.php verlinkte auf ?aktion=... statt
?action=..., wodurch die Vorderseite/Rueckseite-Buttons nie griffen.
Preis-pro-Strich-Vorbelegung kommt jetzt aus tenant_settings statt der
seit M3 nicht mehr gepflegten kl_config-Tabelle.
- Live getestet: isolierter Test-Mandant, Picker zeigt nur eigene
Teilnehmer, Buchungen rein Ledger-nativ mit korrektem Saldo, 10-Striche-
Schwelle korrekt sortiert, Default-Mandant-Dual-Write weiterhin gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hinweise:
- Neue Tabelle notices (tenant-scoped, Soft-Delete via deleted_at) loest
die global unscoped kl_hinweise als aktive Datenquelle ab; Migration
uebernimmt einmalig aktuell gueltige kl_hinweise-Eintraege fuer den
Default-Mandanten. kl_hinweise bleibt als Golden-Master-Referenz stehen.
- hinweise.php und der Banner in header.php sind tenant-scoped umgestellt.
Mitgliederverwaltung:
- mitarbeiterverwalten.php verwaltet jetzt participants (tenant-scoped)
statt der global unscoped kl_Mitarbeiter-Tabelle als primaere Quelle.
Das behebt nebenbei ein Mandanten-Datenleck: jeder SaaS-Mandant mit
Owner/Admin-Rolle haette zuvor die komplette Default-Mandanten-
Mitgliederliste sehen und bearbeiten koennen.
- Fuer den Default-Mandanten bleibt Dual-Write nach kl_Mitarbeiter
bestehen, damit stricheintragen.php/einzahlung.php weiter funktionieren;
andere Mandanten werden rein participant-nativ verwaltet.
- Die Legacy-Administrator-Checkbox ist raus. Stattdessen kann ein Admin
je Mitglied unabhaengig von Name/E-Mail einen Login-Zugang mit Rolle
(member/treasurer/admin) gewaehren oder entziehen
(saas_grant_participant_access / saas_revoke_participant_access).
Einladung laeuft ueber den bestehenden Passwort-Reset-Mechanismus,
Entzug setzt die Mitgliedschaft auf revoked statt sie zu loeschen.
- Kompletter Flow live getestet: anlegen, Zugang gewaehren, Einladungsmail,
Passwort setzen, Login, Rollenschutz, Zugang entziehen, Login-Sperre.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- mitarbeiterverwalten.php war rein ueber Legacy-Admin gesperrt und haette
neue SaaS-Mandanten ausgeschlossen; jetzt Rollen-/Legacy-Fallback wie in
kaffeeliste.php (owner/admin).
- Anlegen/Bearbeiten/Aktivieren/Deaktivieren spiegeln transaktional nach
participants (ledger_mirror_legacy_participant neu ergaenzt), damit
Ledger-Ansichten sofort den aktuellen Mitgliederstand zeigen.
- Gespeicherte XSS-Luecke behoben: Name/E-Mail waren in Formular und Liste
ungeschuetzt ausgegeben, jetzt ueber saas_html().
- Admin-Rollenvergabe bleibt bewusst Legacy-only (kein automatischer
Login-Account ohne Einladungsflow); dokumentiert als offener Punkt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- stricheintragen.php und einzahlung.php erhielten bisher gar keine
Zugriffskontrolle (nur CSRF), jetzt Rollen-/Legacy-Fallback wie in
kaffeeliste.php; Sammeleintraege spiegeln transaktional ins Ledger
(ledger_mirror_legacy_payment neu ergaenzt).
- letzteneintraege.php war rein ueber Legacy-Admin gesperrt und haette
neue SaaS-Mandanten ausgeschlossen; Loeschen markiert den gespiegelten
Ledger-Eintrag jetzt per voided_at statt ihn zu entfernen
(ledger_void_entry_by_legacy_id).
- check-m4-ledger-migration.php an das Storno-Modell angepasst: verwaiste
Ledger-Zeilen sind nur noch ein Fehler, wenn sie nicht voided sind.
- Nebenbei: PHP-Warning bei Sammelerfassung behoben, toten Code entfernt,
veraltete README (verwies auf nicht existierende saas-app/-Struktur)
korrigiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
clemensandClaude Sonnet 5