diff --git a/app/ledger.php b/app/ledger.php index e6d8b86..1593b33 100644 --- a/app/ledger.php +++ b/app/ledger.php @@ -319,6 +319,36 @@ function ledger_mirror_legacy_consumption(PDO $pdo, int $tenantId, int $legacyCo } } +/** + * Mirrors a single kl_Mitarbeiter row into participants, so member changes + * made through the legacy admin UI are immediately visible to ledger-backed + * reads instead of waiting for the next scripts/backfill-default-tenant.php run. + */ +function ledger_mirror_legacy_participant(PDO $pdo, int $tenantId, int $legacyMitarbeiterId): void +{ + $stmt = $pdo->prepare( + "INSERT INTO participants + (tenant_id, display_name, email, email_norm, paypal_name, active, legacy_mitarbeiter_id) + SELECT + ?, + NULLIF(TRIM(m.Name), ''), + NULLIF(TRIM(m.Email), ''), + NULLIF(LOWER(TRIM(m.Email)), ''), + NULLIF(TRIM(m.paypalname), ''), + m.aktiv, + m.MitarbeiterID + FROM kl_Mitarbeiter m + WHERE m.MitarbeiterID = ? + ON DUPLICATE KEY UPDATE + display_name = COALESCE(VALUES(display_name), participants.display_name), + email = VALUES(email), + email_norm = VALUES(email_norm), + paypal_name = VALUES(paypal_name), + active = VALUES(active)" + ); + $stmt->execute([$tenantId, $legacyMitarbeiterId]); +} + function ledger_mirror_legacy_payment(PDO $pdo, int $tenantId, int $legacyPaymentId): void { $stmt = $pdo->prepare( diff --git a/docs/m5-app-kern.md b/docs/m5-app-kern.md index caafb00..e31e671 100644 --- a/docs/m5-app-kern.md +++ b/docs/m5-app-kern.md @@ -127,12 +127,52 @@ Alle drei Flows wurden gegen die Remote-Dev-Datenbank live per HTTP getestet `letzteneintraege.php`) und anschließend wieder auf den Ausgangsstand zurückgesetzt. +## Fortsetzung: Mitgliederverwaltung + +Umgesetzte Dateien: + +```text +mitarbeiterverwalten.php +app/ledger.php +``` + +Umfang: + +- Zugriff nutzte bisher ausschließlich `checkKaffeelisteAdmin` und hätte neue + SaaS-Mandanten ohne Legacy-Mitarbeiterzeile ausgeschlossen. Jetzt gilt die + gleiche Rollen-/Fallback-Logik wie in `kaffeeliste.php`, mit den Rollen + `owner` und `admin` (nicht `treasurer`, da Mitgliederpflege sensibler ist + als reine Zahlungsvorgänge). +- Anlegen, Bearbeiten, Aktivieren und Deaktivieren schreiben weiterhin zuerst + in `kl_Mitarbeiter` und spiegeln danach in derselben Transaktion über die + neue Funktion `ledger_mirror_legacy_participant()` nach `participants`. + Ledger-Ansichten (Dashboard, Kaffeeliste, Teilnehmerauswertung) sehen neue + oder geänderte Mitglieder damit sofort, ohne auf einen manuellen Lauf von + `scripts/backfill-default-tenant.php` zu warten. +- Eine gespeicherte-XSS-Lücke wurde behoben: Name und E-Mail wurden beim + Bearbeiten-Formular und in der Mitgliederliste bisher ungeschützt + ausgegeben (nur `paypalname` war escaped). Beide Stellen nutzen jetzt + `saas_html()`. +- Live gegen die Dev-Datenbank getestet: Anlegen mit einem + HTML/Skript-Payload im Namen (korrekt escaped in der Ausgabe, korrekt + gespiegelt in `participants`), Deaktivieren (spiegelt `active = 0`). + +Bewusst nicht umgesetzt: + +- Der Haken "Administrator" bleibt ein reines Legacy-Feld auf + `kl_Mitarbeiter.admin` und wird nicht automatisch in eine + `tenant_memberships`-Rolle übersetzt. Das würde einen Login-Account ohne + Einladung/Passwort-Setzung anlegen, was ein eigenes, sauber zu + bauendes Einladungs-Flow braucht (E-Mail-Versand, Token, Passwortsetzung). + Admin-Rollen für neue SaaS-Nutzer laufen bis dahin weiter über + `scripts/backfill-default-tenant.php` oder die Registrierung. + ## Noch offen - Eigene PayPal-/Zahlungsbereich als eigenständiger App-Screen (aktuell nur im Dashboard integriert). -- Mitgliederverwaltung tenant- und rollenbasiert umsetzen - (`mitarbeiterverwalten.php` ist noch nicht angefasst). +- Einladungs-Flow, um bestehenden Teilnehmern nachträglich einen + Login-Account mit `tenant_memberships`-Rolle zuzuweisen. - Hinweise als tenant-spezifische Notices umsetzen. - Export, Mail und Jahresprozesse bleiben M6-Themen. @@ -144,3 +184,6 @@ zurückgesetzt. - HTTP-Smoke: grün mit 23 geprüften Seiten. - Live-Test der Schreibflows gegen die Dev-DB: Sammelstriche, Sammeleinzahlung und Storno beider Buchungsarten erfolgreich geprüft. +- Live-Test der Mitgliederverwaltung gegen die Dev-DB: Anlegen (inklusive + XSS-Payload-Check), Deaktivieren, participants-Spiegelung erfolgreich + geprüft. diff --git a/mitarbeiterverwalten.php b/mitarbeiterverwalten.php index 3c18dc4..cca06fa 100644 --- a/mitarbeiterverwalten.php +++ b/mitarbeiterverwalten.php @@ -2,6 +2,7 @@ include "functions.php"; +require_once __DIR__ . "/app/ledger.php"; app_require_csrf(); include "header.php"; include "headerline.php"; @@ -17,66 +18,89 @@ include "nav.php"; beginTransaction(); - // Füge die MitarbeiterID nur bei Bearbeitung hinzu - if ($aktion === 'bearbeitenspeichern' ) { - array_push($params, $mitgliedID); - }elseif($aktion === 'aktivieren' || $aktion === 'deaktivieren'){ - $params = array($mitgliedID); - } + $stmt = $pdo->prepare($sql); + $stmt->execute($params); - $stmt = sqlsrv_query($conn, $sql, $params); + $legacyMitarbeiterId = $aktion === 'anlegen' ? (int)$pdo->lastInsertId() : (int)$mitgliedID; + ledger_mirror_legacy_participant($pdo, $tenantId, $legacyMitarbeiterId); - if ($stmt === false) { - throw new Exception(print_r(sqlsrv_errors(), true)); - } + $pdo->commit(); return true; // Erfolgreich - } catch (Exception $e) { - return $e->getMessage(); // Fehlermeldung zurückgeben + } catch (Throwable $e) { + if ($pdo->inTransaction()) { + $pdo->rollBack(); + } + + return 'Die Aktion konnte nicht gespeichert werden.'; } }?> prepare("SELECT * FROM kl_Mitarbeiter WHERE MitarbeiterID = ?"); + $stmtEinzelmitglied->execute([$mitgliedID]); + $einzelmitglied = $stmtEinzelmitglied->fetch(); ?> -