Noch keine Umsetzung - nur Datenmodell, Ablaeufe und Reihenfolge zum
Abschaetzen. Zwei unabhaengig lieferbare Stufen: erst Magic-Link (klein und
stellt danach den Notzugang bereit), dann OIDC gegen Entra ID.
Festgehaltene Entscheidungen: OIDC statt SAML, ADFS indirekt ueber Entra,
kein automatisches Anlegen von Konten beim SSO-Login, SSO-Pflicht pro Mandant
mit Magic-Link als Notzugang fuer owner/admin.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- mandant-einstellungen.php: vollstaendige Tarif-Vergleichstabelle statt nur
erzwungenem Upgrade-Hinweis. Jeder Tarif zeigt Limit, Preis und einen
Aktions-Button (Buchen/Kuendigen/Anfragen); aktueller Tarif markiert,
zu kleine Tarife fuer die aktuelle Teilnehmerzahl deaktiviert.
- abo-upgrade.php: unterscheidet jetzt Upgrade, Downgrade zwischen bezahlten
Stufen (Preis wird in-place gewechselt statt neuer Checkout-Session,
Stripe prorated automatisch) und Wechsel auf 'free' (echte Kuendigung der
bestehenden Subscription), statt nur eine Checkout-Session zu erzeugen.
- app/stripe.php: neue Helper stripe_get_subscription(),
stripe_update_subscription_price(), stripe_cancel_subscription().
- app/billing.php: billing_plan_selectable_for() prueft serverseitig, ob
ein Zieltarif die aktuelle Teilnehmerzahl noch abdeckt (Downgrade-Schutz).
- docs/billing.md: Phase 4 dokumentiert.
Getestet: php -l fuer alle geaenderten Dateien und das gesamte Repo (keine
Syntaxfehler), reine Funktionslogik-Tests ohne DB (billing_plans(),
billing_required_plan_code(), stripe_flatten_params()) gruen. Kein Live-Test
gegen echte Stripe-Testobjekte moeglich (keine PHP/DB-Laufzeitumgebung
verfuegbar) - vor Go-Live im Stripe-Testmodus nachholen.
Der PDF-Export war bisher immer zweiseitig (Vieltrinker-/Wenigtrinker)
mit fester Mindestzeilenzahl, unabhängig von der tatsächlichen
Mitgliederzahl. Umgestellt auf:
- Bis 49 aktive Mitglieder: eine Seite ohne Trennung.
- Ab 50 Mitgliedern: weiterhin zwei Seiten (Vorder-/Rückseite).
- Zeilenhöhe richtet sich nach der Mitgliederzahl (16-40px), statt fest
16px für alle.
- Neue Mandanten-Einstellungen: freie Zeilen für neue Mitglieder an/aus,
Trennmodus bei zwei Seiten (Trinkverhalten oder alphabetisch).
Migration 0015 ergänzt die dafür nötigen tenant_settings-Spalten.
Gegen die Dev-DB verifiziert: 8 Mitglieder -> einseitiges PDF,
53 Mitglieder (temporäre Testdaten) -> zweiseitiges PDF, Einstellungen
inkl. Validierung geprüft.
Statt automatisch hochzustufen, blockiert das Anlegen/Reaktivieren
weiterer aktiver Mitglieder, sobald das Limit des gebuchten Tarifs
erreicht ist (Neuanlage, Bearbeiten mit Statuswechsel, Aktivieren-
Button). mitarbeiterverwalten.php zeigt die aktuelle Auslastung an.
Neuer Regressionstest scripts/check-billing-capacity.php deckt alle
drei Enforcement-Stellen ab.
Bei erfolgreicher Stripe-Zahlung (invoice.paid) wird automatisch ein
Dolibarr-Kunde ermittelt/angelegt und eine validierte Rechnung als
Buchhaltungsspiegel erzeugt. Dolibarr-Fehler blockieren die
Stripe-Webhook-Verarbeitung nicht, sondern landen im Audit-Log zur
manuellen Nachbearbeitung. Getestet gegen die produktive
Dolibarr-Instanz des Kunden (kein Sandbox verfuegbar) mit einem
rechtebeschraenkten API-Key und einem nicht validierten Test-Datensatz.
Kunde hat nur eine produktive Dolibarr-Instanz. Testansatz angepasst:
rechtebeschraenkter API-Key, Test ueber Entwurfs-Rechnungen gegen einen
dedizierten Test-Kunden statt Sandbox-Vorabtest.
app/stripe.php: minimaler REST-Client fuer die Stripe-API auf Basis von
PHP-Streams statt eines vendorten SDKs - diese PHP-Installation hat keine
curl-Extension, Streams sind zudem portabler und brauchen kein
composer.json.
- Fuer jeden bezahlten Tarif per API ein Stripe-Produkt mit monatlichem
Preis angelegt, referenziert ueber einen stabilen lookup_key statt
hartcodierter Price-ID; Erstellung ist idempotent.
- abo-upgrade.php: erstellt eine Stripe-Checkout-Session fuer den
gewaehlten Tarif, tenant_id/plan_code als Metadaten auf Session UND
Subscription (damit spaetere Subscription-Events zuordenbar bleiben).
- abo-portal.php: oeffnet das Stripe Customer Portal fuer bestehende
Kunden (Zahlungsmittel/Kuendigung, ohne eigene UI dafuer).
- stripe-webhook.php: verifiziert die Stripe-Signature per HMAC-SHA256
mit Zeitstempel-Toleranz, verarbeitet checkout.session.completed,
customer.subscription.updated/.deleted, invoice.paid/.payment_failed
und haelt tenant_billing aktuell. Bewusst kein CSRF-/Login-Check
(Stripe ruft unauthentifiziert auf), stattdessen ausschliesslich
Signaturpruefung als Echtheitsnachweis.
- mandant-einstellungen.php: echter "Jetzt upgraden"-Button (Stripe
Checkout) sowie "Zahlungsmethode verwalten/Abo kuendigen" (Customer
Portal), sobald ein Stripe-Kunde existiert.
Live getestet (Stripe-Testmodus, kein echtes Geld): voller Checkout-Flow
bis zum echten Redirect auf checkout.stripe.com, Webhook-Verarbeitung
durch selbst erzeugte, korrekt signierte Test-Events (da diese
Dev-Umgebung keine oeffentlich erreichbare URL fuer echte Stripe-
Zustellung hat) inklusive Ablehnung falscher Signaturen, Customer Portal
mit echtem per API angelegtem Test-Kunden. Alle Regressionstests
weiterhin gruen (36 Seiten HTTP-Smoke, Golden Master, M8-Isolation/
Rollenmatrix).
Noch offen: echten Webhook-Endpunkt auf die Produktions-Domain eintragen,
sobald diese feststeht; Wechsel auf Live-Keys; Dolibarr-Sync (Phase 3).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Vorbereitung fuer Stripe Billing (Zahlungseinzug) + bestehendes Dolibarr
des Kunden (Rechnungsstellung/Buchhaltung) statt eines eigenen Rechnungs-
systems oder eines zusaetzlichen ERP nur fuer Kaffeeliste - Begruendung
in docs/billing.md.
- Neue Tabelle tenant_billing (plan_code, subscription_status, sowie
bereits vorbereitete, noch ungenutzte Felder fuer Stripe/Dolibarr-IDs).
- app/billing.php: billing_plans() als einzige Quelle der Tarifstufen
(synchron mit preise.php), billing_required_plan_code() anhand aktiver
Teilnehmerzahl, billing_check_tenant() vergleicht gebuchten mit
benoetigtem Tarif - rein informativ, kein Enforcement, solange Stripe
nicht angebunden ist.
- Neue Mandanten starten automatisch auf plan_code='free' bei der
Registrierung.
- mandant-einstellungen.php zeigt Owner/Admin ihren aktuellen Tarif und
Teilnehmerstand, mit Hinweis bei Bedarf einer hoeheren Stufe.
- Back-Office zeigt zusaetzlich zur Mandantenliste den gebuchten und
(falls abweichend) den tatsaechlich benoetigten Tarif.
Live getestet: Tarifgrenzen (10/25/50/150) mit einem Mandanten unter und
einem ueber dem Freikontingent geprueft, UI in Mandant-Einstellungen und
Back-Office verifiziert. Alle M8-Isolations-/Rollenmatrix-Tests weiterhin
gruen.
Phase 2 (Stripe) und Phase 3 (Dolibarr-Sync) folgen, sobald Test-Keys
beziehungsweise Sandbox-Zugang vorliegen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Ergaenzt die beiden letzten offenen M7-Punkte und schaerft nebenbei die
Copy insgesamt:
- Neue Sektion 'So funktioniert's' mit dem im Plan vorgesehenen
Drei-Schritte-Ablauf (Kaffee nehmen, Strich setzen, bei Bedarf
bezahlen), bisher komplett gefehlt.
- Funktionsuebersicht von drei auf sechs Karten erweitert (Mitglieder/
Rollen, Guthaben/Einzahlungen, PayPal, CSV-Import/-Export,
Mandantenfaehigkeit, Hinweise/Info-Mails) statt der bisherigen,
eher technischen Kurzbeschreibung.
- Demo-Screenshot: bereinigter Screenshot der Gesamtuebersicht mit
Testdaten (keine echten Kundendaten) aus docs/m0/screenshots/ als
assets/images/demo-kaffeeliste.png eingebunden.
- FAQ-Auszug: fuenf produktbezogene Fragen (Einrichtung, Mandanten-
trennung, Rollen, Export/Loeschung, PayPal) direkt auf der
Landingpage. Bewusst nicht die bestehende faq.php excerpted, da die
komplett AOK-spezifisch ist (Kaffeemaschinen-Bedienung, interner
Ansprechpartner) und fuer Interessenten nicht generisch verstaendlich
waere.
- Neue CSS-Klassen fuer Schritte/Demo-Rahmen/FAQ-Grid/Abschluss-CTA in
assets/css/public.css, konsistent mit dem bestehenden Grundton
(gruener Akzent, schlichte Kartenoptik, keine Marketing-Verspieltheit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
docs/betrieb-backup-monitoring.md: taeglicher mysqldump-Cron-Job mit
Aufbewahrung, Restore-Befehl inklusive Hinweis auf scripts/migrate.php,
vierteljaehrlicher Restore-Test. Produktive PHP-Fehlerkonfiguration
(display_errors aus, log_errors an) und die aktiv zu beobachtenden
Signale ohne dediziertes APM-Tool: audit_log fuer ungewoehnliche
Admin-Aktionen, rate_limit_attempts fuer Brute-Force-Versuche,
outbound_emails.status=failed fuer Mailversand-Probleme.
Damit ist M8 fuer den geplanten Scope abgeschlossen, mit einer bewusst
offenen Ausnahme (Content-Security-Policy, braucht Template-Bereinigung
der bestehenden Inline-Styles).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
scripts/check-m8-tenant-isolation.php: legt zwei frische, isolierte
Test-Mandanten mit je einem Teilnehmer, einer Ledger-Buchung, einem
Hinweis und einem Audit-Log-Eintrag an und prueft 10 Faelle - Lesezugriffe
(Teilnehmerlisten, Einzelabruf, letzte Buchungen, aktive Hinweise,
Audit-Log) und Schreibzugriffe (Buchung, Zugangsvergabe, Storno) sind
strikt auf den jeweils richtigen Mandanten beschraenkt. Raeumt sich selbst
auf. 10/10 gruen.
scripts/check-m8-role-matrix.php: legt einen Test-Mandanten mit je einem
Nutzer pro Rolle an (owner/admin/treasurer/member/viewer), loggt sich per
echtem HTTP-Request ein (manueller Cookie-Jar ueber file_get_contents, da
diese PHP-Installation keine curl-Extension hat) und prueft alle elf
rollen-geschuetzten Seiten gegen die erwartete Rollenliste. 55/55 gruen
(5 Rollen x 11 Seiten) - bestaetigt, dass die Rollenpruefungen ueberall
konsistent mit dem im Plan dokumentierten Rollenmodell durchgesetzt sind.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Erste drei Bausteine der Haertung:
- Security-Headers (X-Content-Type-Options, X-Frame-Options, Referrer-
Policy, Permissions-Policy, HSTS bei HTTPS) laufen automatisch ueber
app_send_security_headers() am Ende von app/bootstrap.php fuer jede
dynamische Seite; landing.php war als einzige Seite ganz ohne PHP und
bekam einen minimalen Bootstrap-Aufruf. Bewusst kein CSP, da die
bestehenden Templates durchgaengig auf Inline-style-Attribute setzen.
- DB-gestuetzte Rate-Limits (neue Tabelle rate_limit_attempts) fuer
Login (10/15min je E-Mail, 20/15min je IP), Registrierung (5/h je IP)
und Passwort-Reset-Anfrage (5/h je E-Mail, 10/h je IP); bei
ausgereiztem Reset-Limit erscheint dieselbe generische Meldung wie im
Erfolgsfall, um kein Konto-Enumeration-Signal zu geben.
- Zentrales Audit-Log (neue Tabelle audit_log) fuer Mitgliederverwaltung,
Zugangsvergabe/-entzug, Storno, Mandant-Einstellungen, Hinweise,
CSV-Import, Jahresbonus-Verteilung und Live-Mailversand; sichtbar fuer
Owner/Admin auf mandant-einstellungen.php.
Live getestet: Rate-Limit greift nach 10 Fehlversuchen, Audit-Log-Eintrag
mit korrekten Metadaten und Nutzernamen ueber einen isolierten Test-
Mandanten geprueft. Alle Regressionstests weiterhin gruen (26/26 Smoke,
104 Golden-Master-Assertions).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Klaerung auf Nutzerfrage: saas_send_mail() nutzt produktiv PHP mail()
statt eines externen SMTP-Relays, laeuft also automatisch ueber den
Mailserver des Webspace-Anbieters, der fuer die eigene Domain i.d.R.
bereits autorisiert ist (SPF/rDNS). Dokumentiert die dafuer noetigen
Env-Variablen, insbesondere APP_MAIL_FROM, das produktiv nicht auf dem
Platzhalter noreply@kaffeeliste.local stehen bleiben darf.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jahresauswertung.php verband sich bisher mit fest codierten (kaputten)
Zugangsdaten selbst zur Datenbank statt ueber config.php, hatte keine
Zugriffskontrolle und kein CSRF, und verteilte bei jedem Aufruf sofort
einen hart codierten Bonus-Topf (490 Striche a 0,20 Euro) per PHPMailer
(dessen Quelldateien im Repo fehlen) mit AOK-spezifischem Mailtext.
Nach Abstimmung mit dem Kunden als generisches, mandantenfaehiges Feature
neu gebaut statt nur deaktiviert oder rein lesend umgesetzt:
- Admin gibt einen frei waehlbaren Gesamtbetrag ein, das System verteilt
ihn proportional zu den Jahresstrichen auf alle aktiven Mitglieder.
- Standardmaessig aktive Dry-Run-Checkbox zeigt die Verteilung, ohne zu
buchen oder Mails zu verschicken.
- Bestaetigter Lauf bucht ueber dasselbe Zweig-Muster wie ueberall
(Default-Mandant Dual-Write, andere Mandanten ledger_record_payment)
und verschickt personalisierte Mails ueber saas_send_mail(), protokolliert
im outbound_emails-Versandlog.
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback).
- http-smoke.php: jahresauswertung.php jetzt regulaerer Check statt
uebersprungenem unsicherem Aufruf; damit sind keine Seiten mehr
uebersprungen oder als bekannter offener Punkt markiert (26/26 gruen).
Live getestet: Dry-Run mit korrekter proportionaler Verteilung (Summe
ergibt exakt den Gesamtbetrag), Live-Lauf bucht und versendet korrekt,
Testdaten anschliessend vollstaendig entfernt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mailversenden.php hatte keine Zugriffskontrolle, versendete bei jedem
GET-Request sofort echte Mails und nutzte PHPMailer, dessen Quelldateien
im Repo gar nicht vorhanden waren (nur composer.json/Lizenz) - der Aufruf
waere also ohnehin mit Fatal Error abgebrochen. Zusaetzlich waren SMTP-
Host, Absender, PayPal-Link und FAQ-URL fest auf einen Alt-Kunden (AOK)
codiert.
- Ersetzt PHPMailer durch die bestehende saas_send_mail()-Abstraktion aus
M3 (Transport log/mail je nach APP_MAIL_TRANSPORT) statt eine fehlende
Abhaengigkeit nachzuvendoren.
- Neue Tabelle outbound_emails protokolliert jeden Versandversuch:
Mandant, Mitglied, Vorlage, Betreff, Status, Fehler - das Versandlog.
- Formular hat eine standardmaessig aktive Dry-Run-Checkbox; im Dry-Run
wird nur geloggt, saas_send_mail() nicht aufgerufen.
- Mailtext ist jetzt tenant-generisch (Saldo, optionaler PayPal-Link nur
wenn der Mandant PayPal aktiviert hat, eigener Dashboard-Link) statt
hartcodierter Alt-Kunden-Inhalte.
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback).
- http-smoke.php: mailversenden.php ist jetzt reguel</EOF>
exportKaffeeliste.php band config.php direkt ein (keine Bootstrap-Kette)
und hatte ueberhaupt keine Zugriffskontrolle. TCPDF war im Repo nur
teilweise vorhanden (include/-Verzeichnis und Font-Definitionen fehlten
komplett), wodurch der Export bislang immer mit einem Fatal Error abbrach.
- TCPDF/include/ und die 14 PDF-Standard-Fonts (Helvetica, Courier, Times,
Symbol, ZapfDingbats) aus dem offiziellen TCPDF-6.6.2-Release nachvendort
(nicht die vollen ~25 MB an Unicode-Fonts, die hier nicht gebraucht
werden).
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback wie
bei den anderen Treasurer-Seiten).
- Vieltrinker-/Wenigtrinker-Aufteilung liest jetzt tenant-sicher ueber
ledger_fetch_participants_by_window_marks() statt Legacy-SQL direkt
gegen kl_Kaffeeverbrauch; Preis pro Strich kommt aus tenant_settings
statt kl_config. N+1-Abfragen pro Zeile durch die bereits geladene
Teilnehmerzusammenfassung ersetzt.
- scripts/http-smoke.php prueft den Export jetzt als regulaeren Check
(gueltige PDF-Antwort) statt als bekannten offenen Punkt.
- Live getestet: gueltiges zweiseitiges PDF, Namen/Salden im Textstream
verifiziert, Aufteilung stimmt mit Ledger-Daten ueberein.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
csvupload.php verarbeitete CSV-Zeilen bisher sofort beim Upload, ohne
Vorschau, ohne Zugriffskontrolle (nur CSRF) und schrieb ausschliesslich in
die global unscoped kl_Einzahlungen-Tabelle.
- Neue Tabellen payment_import_batches/payment_import_rows protokollieren
jeden Import: Datei, Pruefsumme, jede Zeile mit Rohwerten, erkanntem
Mitglied, Status und erzeugter Ledger-Zeile.
- Zweistufiger Ablauf: Hochladen zeigt nur eine Vorschau (matched/
duplicate/unmatched/invalid), erst "Import bestaetigen" bucht.
- Zuordnung per paypal_name oder display_name (tenant-scoped), Dubletten-
pruefung gegen bestehende nicht-stornierte Ledger-Zahlungen.
- Buchung folgt dem etablierten Zweig-Muster: Default-Mandant per
Dual-Write nach kl_Einzahlungen plus Spiegelung, alle anderen Mandanten
direkt ueber ledger_record_payment().
- Zugriffskontrolle ergaenzt (owner/admin/treasurer + Legacy-Fallback).
- Live getestet: Treffer, unbekannter Name, ungueltiger Betrag korrekt
klassifiziert; Import bestaetigt mit korrektem Dual-Write; erneuter
Upload derselben Datei erkennt die Zeile korrekt als Dublette.
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>
Uebersichtstabelle und M5-Abschnitt markierten Mitgliederverwaltung,
Storno-Korrekturen und die Sammelerfassung noch als offen, obwohl sie
in dieser Session umgesetzt wurden. Ausserdem dokumentiert: der PayPal-
Bereich ist bewusst im Dashboard gebuendelt statt als eigene Route, wie
urspruenglich in der Zielarchitektur skizziert.
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>
- neue ledger-preview.php mit Tenant-Summen und letzten Ledger-Buchungen bauen
- Admin-Navigation und HTTP-Smoke um Ledger-Preview erweitern
- M4- und Meilenstein-Doku auf Preview-Stand aktualisieren
- gemeinsames Public-CSS fuer Landingpage und Auth-Seiten ergaenzen
- Login, Registrierung und Passwort-/E-Mail-Seiten vom App-Layout trennen
- App-Sidebar von Public-Login- und Registrierungslinks bereinigen
- Webspace- und Subdomain-Strategie dokumentieren
- Mail-Transport fuer Reset- und Verifizierungslinks ergaenzen
- Public-Landingpage mit Hero-Asset und App-CTAs bauen
- Mail-Flow-Test, Smoke-Abdeckung und SaaS-Doku aktualisieren
- 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
- M2-Abschlussstatus und Abschlusskriterien dokumentieren
- M3-SaaS-Basisplan mit Tenant/User/Participant-Modell ergänzen
- Hauptplan mit M2-Abschluss und M3-Startpunkten aktualisieren
- Upload-Formular mit CSRF-Token absichern
- CSV-Dateien temporär unter var/uploads speichern und nach Import löschen
- Dateityp, Dateigröße und Dateiendung prüfen
- CSV-Ausgabe escapen und PayPal-Name-Lookup korrigieren
- M2- und Sicherheitsdokumentation aktualisieren
- Löschaktionen in letzteneintraege.php mit CSRF-Token absichern
- POST ohne Token für Einzahlungen und Strich-Einträge blockieren
- M2- und Sicherheitsdokumentation zum CSRF-Rollout aktualisieren
clemensandClaude Opus 4.8