M6: Jahresabschluss als generisches Feature statt AOK-spezifischem Bonus-Skript
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>
This commit is contained in:
@@ -149,10 +149,58 @@ Live-Versand erzeugt für jeden Empfänger eine Log-Datei mit korrekt
|
||||
personalisiertem Inhalt (Guthaben- und Schuldenfall geprüft), Versandlog in
|
||||
der UI zeigt die Einträge. Testdaten anschließend entfernt.
|
||||
|
||||
## Jahresabschluss
|
||||
|
||||
Umgesetzte Dateien:
|
||||
|
||||
```text
|
||||
app/saas-mail.php (Mailvorlage)
|
||||
jahresauswertung.php
|
||||
scripts/http-smoke.php
|
||||
```
|
||||
|
||||
Ziel: Ein generisches, mandantenfähiges Feature statt der ursprünglichen
|
||||
AOK-spezifischen Alt-Kunden-Logik.
|
||||
|
||||
Hintergrund: `jahresauswertung.php` verband sich bisher mit fest codierten
|
||||
(kaputten) Zugangsdaten selbst zur Datenbank statt über `config.php`, hatte
|
||||
keinerlei Zugriffskontrolle und kein CSRF, verteilte bei jedem Aufruf sofort
|
||||
einen hart codierten Bonus-Topf (490 Striche à 0,20 €) und verschickte
|
||||
dabei über PHPMailer (dessen Quelldateien im Repo fehlen) Mails mit
|
||||
AOK-spezifischem Text. Mit dem Nutzer wurde abgestimmt, daraus ein echtes,
|
||||
wiederverwendbares Feature zu bauen statt es nur zu deaktivieren oder rein
|
||||
lesend umzusetzen.
|
||||
|
||||
Umfang:
|
||||
|
||||
- Admin gibt einen frei wählbaren Gesamtbetrag ein; das System verteilt ihn
|
||||
proportional zu den in diesem Kalenderjahr gemachten Strichen
|
||||
(`year_marks` aus `ledger_fetch_participant_summaries()`) auf alle
|
||||
aktiven Mitglieder.
|
||||
- Standardmäßig aktive Dry-Run-Checkbox zeigt Name, Jahresstriche, Anteil
|
||||
und berechneten Bonus, ohne zu buchen oder Mails zu verschicken.
|
||||
- Bei bestätigtem Lauf wird pro Mitglied mit einem Anteil > 0 eine
|
||||
Zahlung gebucht (gleiches Zweig-Muster wie überall: Default-Mandant per
|
||||
Dual-Write nach `kl_Einzahlungen` plus Spiegelung, andere Mandanten
|
||||
direkt über `ledger_record_payment()` mit `source = year_end_bonus`) und
|
||||
eine personalisierte Mail über `saas_send_mail()` verschickt und im
|
||||
Versandlog (`outbound_emails`, Vorlage `year_end_bonus`) protokolliert.
|
||||
- Zugriffskontrolle ergänzt (owner/admin/treasurer + Legacy-Fallback).
|
||||
- `scripts/http-smoke.php`: `jahresauswertung.php` ist jetzt ein regulärer
|
||||
Check statt eines übersprungenen unsicheren Aufrufs, da GET keine
|
||||
Seiteneffekte mehr hat.
|
||||
|
||||
Live getestet: Dry-Run mit 100 € (korrekte proportionale Verteilung,
|
||||
Summe der Einzelbeträge ergibt exakt den Gesamtbetrag, keine Buchungen oder
|
||||
Mails), anschließender Live-Lauf bucht korrekt (Dual-Write und
|
||||
Ledger-Spiegelung stimmen mit den berechneten Beträgen überein) und
|
||||
verschickt personalisierte Mails; Versandlog zeigt alle Einträge korrekt.
|
||||
Testdaten anschließend vollständig 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 25 geprüften Seiten (PDF-Export und Mailversand
|
||||
jetzt regulär statt bekannter offener Punkte).
|
||||
- HTTP-Smoke: grün mit 26 geprüften Seiten, keine übersprungenen oder
|
||||
bekannten offenen Punkte mehr.
|
||||
|
||||
@@ -306,7 +306,7 @@ Nicht tun:
|
||||
| M3 | SaaS-Basis | Abgeschlossen: Tenants, User, Registrierung, Login, Rollen, Mail-Links und zentrale Mandantenauswahl funktionieren |
|
||||
| M4 | Datenmigration | Gestartet: Ledger-Tabelle, Legacy-Backfill, Paritätscheck, Ledger-Service und Preview sind umgesetzt |
|
||||
| M5 | App-Kern | Weit fortgeschritten: Kernseiten lesen und schreiben tenant-sicher gegen das Ledger, inklusive Hinweise und rollenbasiertem Zugang; offen ist ein eigener Zahlungs-Screen |
|
||||
| M6 | Betriebsflows | Weit fortgeschritten: CSV-Import, PDF-Export und Mailversand stehen; Jahresprozesse offen |
|
||||
| M6 | Betriebsflows | Abgeschlossen: Import, Export, Mail und Jahresabschluss sind auditierbar |
|
||||
| M7 | Landingpage | Public-Seite und Auth-Seiten sind im gemeinsamen Stil nutzbar; spätere Ausbaustufen folgen |
|
||||
| M8 | Härtung | Betrieb, Datenschutz, Monitoring und Isolation sind geprüft |
|
||||
| M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only |
|
||||
@@ -585,13 +585,21 @@ Schritte:
|
||||
PayPal-Link, FAQ-URL). Ersetzt durch die bestehende `saas_send_mail()`-
|
||||
Abstraktion aus M3, eine neue `outbound_emails`-Tabelle als Versandlog
|
||||
und eine standardmäßig aktive Dry-Run-Option.
|
||||
- Jahresauswertung beziehungsweise Jahresbuchungen tenant-sicher abbilden.
|
||||
- Jahresauswertung beziehungsweise Jahresbuchungen tenant-sicher abbilden:
|
||||
erledigt. Die ursprüngliche Seite verband sich mit fest codierten,
|
||||
kaputten Zugangsdaten selbst zur Datenbank (an `config.php` vorbei),
|
||||
hatte keine Zugriffskontrolle und verteilte bei jedem Aufruf sofort einen
|
||||
hart codierten Bonus-Topf mit AOK-spezifischem Mailtext. Nach Abstimmung
|
||||
mit dem Kunden als generisches Feature umgesetzt: frei wählbarer
|
||||
Gesamtbetrag, proportionale Verteilung nach Jahresstrichen, Dry-Run,
|
||||
Buchung und Mailversand mit Protokoll.
|
||||
|
||||
Ergebnis:
|
||||
|
||||
- Kassenverwaltung ist für reale Betriebsabläufe vollständig.
|
||||
- Import/Export/Mail sind auditierbar.
|
||||
- Stand: gestartet. Dokumentation: `docs/m6-import-export-mail.md`.
|
||||
- Stand: abgeschlossen für den M6-Scope. Dokumentation:
|
||||
`docs/m6-import-export-mail.md`.
|
||||
|
||||
Abhängigkeiten:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user