- 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.
2.6 KiB
2.6 KiB
offene Aufgaben: sortiere die Aufgaben nach korrekter Reihenfolge, schreibe nach dieser zeile um für KI-Lesbarkeit, fertige aufgaben durchstreichen und als erledigt markieren.
Reihenfolge unten nach Abhängigkeit/Aufwand sortiert (nicht nach ursprünglicher Nummerierung). Punkt "Docker" wurde in zwei getrennte Aufgaben aufgeteilt, da "in Docker packen" und "Migration zu React+Postgres" völlig unterschiedlicher Umfang sind und nicht als ein Task behandelt werden sollten.
-
1. Demo-Login für Vorführungen(erledigt)Eigener Login, zeigt eine erfundene/fiktive Person als "Familienmitglied"Nutzer kann im Demo-Modus eine Test-Person anlegenDemo-Inhalte müssen komplett vorausgefüllt sein (nicht leer)Demo-Datenbestand setzt sich automatisch alle 6 Stunden zurück- Umsetzung:
nutzer.ist_demo-Konto "demo"/"demo", "Demo ausprobieren"-Button auf dem Login-Screen, "Demo-Modus"-Badge in der Topbar, vorausgefüllte fiktive Patientin "Grete Musterfrau" (Antrag, 2 Leistungen, 2 Aufgaben, Pflegetagebuch), Lazy-Reset alle 6h bei Login/Request (kein Cron/Thread nötig), E-Mail-Versand im Demo-Konto gesperrt (403), Demo-Konto von der Abo-Zahlungspflicht ausgenommen. Details siehe CLAUDE.md.
-
2. Docker-Containerisierung der aktuellen App (Flask + SQLite, kein Rewrite)
- App als Docker-Image/Compose-Setup lauffähig machen, so wie sie heute ist
- Isolierung zwischen App-Container und Datenbank (getrennte Services/Volumes)
- Keine Secrets/Env-Werte in der docker-compose.yml selbst — eigene .env-Datei dafür (keine .env.example nötig, Solo-Projekt)
- Ports müssen über Variablen konfigurierbar sein, nicht hart codiert
-
3. Update-Benachrichtigung / Changelog-System
- Nach dem ersten Login nach einem Update: kurzer anklickbarer Hinweis, was sich geändert hat
- Ein Klick auf "Gelesen" reicht, um den Hinweis zu schließen
- Optional: dauerhaftes Icon in der Sidebar, um alle vergangenen Changelogs als Historie nachzulesen
- Setzt eine einfache Versionierung des Deployments voraus (siehe Punkt 4 unten), damit die App weiß, "was ist neu seit dem letzten Login"
-
4. ⚠️ Separates Grossvorhaben: Migration zu React + PostgreSQL
- Vollständiger Technologiewechsel weg von Flask/vanilla-JS/SQLite — deutlich grösserer Umfang als die Punkte oben, keine Nebenbei-Aufgabe
- Braucht eine eigene Versionierungs-/Update-Strategie, da die App online ist und nicht für immer im jetzigen Stack bleiben wird
- Bevor hier irgendetwas beginnt: eigene Planungsrunde nötig (Umfang, Reihenfolge der Migration, ob schrittweise oder Neubau, Datenmigration aus der bestehenden SQLite-DB)