Files
pflegefuchs/open.md
T
admin af43371a5b Demo-Login fuer Vorfuehrungen (open.md Punkt 1)
- 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.
2026-07-18 17:48:48 +02:00

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 anlegen
    • Demo-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)