clemensandClaude Sonnet 5
92e124753f
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>
2.6 KiB
2.6 KiB
M6 Import, Export und Mail
Stand: 2026-07-15
M6 macht die Admin-/Treasurer-Flows produktionsreif: CSV-Import, PDF-/Listenexport, Mailversand und Jahresprozesse laufen tenant-sicher gegen das neue Modell statt gegen Legacy-Tabellen direkt.
CSV-Import
Umgesetzte Dateien:
database/migrations/0008_saas_payment_imports.sql
app/imports.php
csvupload.php
Ziel: Zahlungsimport mit echter Vorschau, Dublettenprüfung und Audit-Trail, statt sofortiger Verarbeitung ohne Bestätigungsschritt wie im Legacy-Stand.
Umfang:
- Neue Tabellen
payment_import_batchesundpayment_import_rows(siehe Kernschema im Umstrukturierungsplan) protokollieren jeden Import: Datei, Prüfsumme, Zeitpunkt, jede einzelne Zeile mit Rohwerten, erkanntem Mitglied, Status und – nach Bestätigung – der erzeugten Ledger-Zeile. - Zweistufiger Ablauf: Hochladen erzeugt eine Vorschau (
status = previewed) ohne jede Buchung; erst der zweite Schritt „Import bestätigen“ committet die alsmatchederkannten Zeilen (status = committed). - Zeilen werden klassifiziert:
matched(wird gebucht),duplicate(gleicher Teilnehmer, gleicher Betrag, gleicher Tag existiert bereits als nicht-stornierte Ledger-Zahlung),unmatched(kein Mitglied perpaypal_nameoderdisplay_namegefunden),invalid(Betrag oder Datum nicht parsebar). - Zuordnungsregel entspricht der Legacy-Logik: Name aus der CSV wird gegen
paypal_nameoderdisplay_nameverglichen (case-insensitiv). - Buchung folgt demselben Zweig-Muster wie die übrige Sammelerfassung: Für
Teilnehmer mit
legacy_mitarbeiter_id(Default-Mandant) wird zusätzlich einekl_Einzahlungen-Zeile geschrieben und gespiegelt; alle anderen Mandanten werden direkt überledger_record_payment()gebucht. - Zugriffskontrolle ergänzt: Die Seite hatte zuvor gar keine Prüfung außer
CSRF. Jetzt gilt dieselbe Rollen-/Legacy-Fallback-Logik wie bei
einzahlung.php(owner,admin,treasurer). - Upload-Härtung aus M2 (Größen-/Typprüfung, Speicherung außerhalb des
direkt erreichbaren Codes unter
var/uploads, Löschung nach Verarbeitung) bleibt erhalten.
Live gegen die Dev-Datenbank getestet: Upload mit drei Testzeilen (Treffer, unbekannter Name, ungültiger Betrag), Vorschau-Klassifizierung geprüft, Import bestätigt (Dual-Write und Ledger-Spiegelung korrekt), erneuter Upload derselben Datei erkennt die bereits importierte Zeile korrekt als Dublette. Testdaten anschließend entfernt.
Prüfstatus
- Golden Master: grün mit 104 Assertions.
- M4 Ledger-Migration: grün mit 73 Assertions.
- M4 Ledger-Service: grün mit 115 Assertions.
- HTTP-Smoke: grün mit 23 geprüften Seiten.