admin
af43371a5b
- nutzer.ist_demo-Spalte, permanentes Konto demo/demo wird in init_db() automatisch angelegt - Vorausgefuellte fiktive Patientin "Grete Musterfrau" (Pflegegrad 3, 1 Antrag, 2 Leistungen, 2 Aufgaben, 1 Pflegetagebuch-Eintrag) - _demo_seed() - Automatischer Reset alle 6 Stunden per Lazy-Check (kein Cron/Thread noetig): _demo_reset_faellig()/_demo_reset() geprueft bei Login und bei jedem Request (global_auth_check), damit auch eine laufende Sitzung die 6h-Grenze nicht verpasst - Demo-Konto von der Abo-Zahlungspflicht ausgenommen (_hat_aktiven_ zugang) - wurde erst beim Testen entdeckt: bei aktiver Zahlungspflicht waere das Demo-Konto sonst mit "Zahlung erforderlich" ausgesperrt worden, was fuer eine Vorfuehrung inakzeptabel waere - E-Mail-Versand (api/email/senden + /test) fuer das Demo-Konto gesperrt (403) - verhindert Missbrauch der echten SMTP-Konfiguration durch Demo-Besucher - Login-Screen: neuer "Demo ausprobieren"-Button; Topbar zeigt waehrend einer Demo-Sitzung ein "Demo-Modus"-Badge open.md: Reihenfolge sortiert (Docker-Containerisierung und React+ Postgres-Migration als getrennte Aufgaben markiert, da voellig unterschiedlicher Umfang), Punkt 1 als erledigt markiert. Verifiziert: Login, vorausgefuellte Patientendaten, Isolation (Demo sieht nur eigene Patientin), erzwungener Reset (Patient-ID aendert sich, demo_reset_at aktualisiert), E-Mail-Sperre (403), Abo-Ausnahme (Zugriff bleibt moeglich auch bei abo_pflicht=1), Login-Button und Demo-Badge visuell per Playwright bestaetigt.