Empfang V4: Auth, Praxis-Tenant, Cockpit, Caddy-Rewrite

Made-with: Cursor

AzA march 2026/handover.md

@@ -73,7 +73,185 @@ medizinisch und AZA-konform umgesetzt.
   Push-Notifications.
 
 **Oeffentliche Subdomain:** empfang.aza-medwork.ch (DNS A-Record auf Hetzner,
-Caddy-Block bereits konfiguriert).
+Caddy-Block konfiguriert, Root wird transparent auf /empfang/ rewritten).
+
+### 6. AZA Praxis-Tenant-Chat Architektur (VERBINDLICH, 2026-04-18)
+
+Interne Kurzbezeichnung: **AZA Praxis-Tenant-Chat Architektur**
+
+#### 6.1 Mandantenmodell (Tenant = Praxis)
+
+Eine Praxis / Organisation ist die oberste Einheit. Nicht "eine Lizenz = ein Chat",
+sondern: Praxis = Mandant = Vertrauensraum.
+
+- Lizenzen haengen an der Praxis (nicht am einzelnen Benutzer)
+- Mehrere Lizenzen einer groesseren Praxis speisen denselben Praxisraum
+- Benutzer, Chats, Aufgaben, Dateien gehoeren immer zu genau einer Praxis
+- Trennung NIEMALS nur ueber sichtbare Namen – immer ueber `practice_id`
+
+#### 6.2 Kerndatenmodell
+
+| Entitaet | Primaerschluessel | Scope | Beschreibung |
+|---|---|---|---|
+| Practice | `practice_id` (UUID) | Global | Praxis / Organisation / Mandant |
+| User | `user_id` (UUID) | practice_id | Benutzer innerhalb einer Praxis |
+| Device | `device_id` (UUID) | user_id | Geraet eines Benutzers |
+| Channel | `channel_id` (UUID) | practice_id | Chat-Kanal (Allgemein, Empfang, Aerzte, ...) |
+| Message | `message_id` (UUID) | channel_id | Einzelne Nachricht in einem Kanal |
+| Thread | `thread_id` (UUID) | channel_id | Gruppierung von Nachrichten |
+| Task | `task_id` (UUID) | practice_id | Aufgabe mit Zuweisung |
+| File | `file_id` (UUID) | practice_id | Anhaenge / Bilder / Dokumente |
+| Session | `session_id` (UUID) | user_id + device_id | Authentifizierte Sitzung |
+
+#### 6.3 Rollenmodell
+
+Pflicht-Rollen (V1):
+- **Practice Admin** – Benutzer einladen, Rollen aendern, Geraete erlauben/sperren/loeschen, Praxisverbindungen freigeben
+- **Arzt** – Voller Chat-/Aufgaben-Zugriff, KG-Senden
+- **MPA** – Chat-/Aufgaben-Zugriff, Empfangsfunktionen
+- **Empfang** – Chat-/Aufgaben-Zugriff, primaer Empfangsfunktionen
+
+Spaeter optional:
+- Externe Praxis (Verbindung per Einladungscode)
+- Lesend (Gast)
+- Weitere interne Rollen
+
+NUR Practice Admin darf:
+- Benutzer einladen / entfernen
+- Rollen aendern
+- Geraete erlauben / sperren / loeschen
+- Praxisverbindungen freigeben
+- Audit-Log einsehen
+
+#### 6.4 Geraeteverwaltung
+
+Jedes Geraet hat:
+- `device_id` (UUID)
+- Geraetename (z.B. "Praxis-PC Empfang", "Arzt-Laptop zuhause")
+- Plattform (Windows/macOS/iOS/Android/Browser)
+- Letzter Zugriff (Zeitstempel)
+- Vertrauensstatus (trusted / pending / blocked)
+- Zugehoerigkeit: user_id + practice_id
+
+Admin-Aktionen: erlauben, sperren, loeschen, erneute Anmeldung erzwingen.
+Sichtbar: Praxis-PC Empfang, Arzt-Laptop, iPhone, Apple Watch, alte Geraete.
+
+#### 6.5 Mobilgeraet-Kopplung (Variante A – VERBINDLICH)
+
+Bevorzugter Kopplungspfad:
+1. Admin/Benutzer waehlt im Web/Desktop: "Mobilgeraet koppeln"
+2. System erzeugt QR-Code (enthaelt Einmal-Token + practice_id + user_id)
+3. Handy-App scannt QR-Code
+4. Serverseitig: sichere Geraetebindung wird erstellt
+5. Geraet erscheint in der Geraeteliste des Admins
+
+KEIN loses offenes Handy-Login. QR-Code + serverseitige Bestaetigung.
+
+#### 6.6 Browser-Zugang von zuhause
+
+Benutzer duerfen von zuhause ueber den Browser arbeiten, aber NUR wenn:
+- Benutzer wurde eingeladen und Konto ist aktiv
+- Geraet ist bestaetigt / vertraut
+- Praxiszugehoerigkeit (practice_id) stimmt
+- Session ist gueltig (JWT/Token)
+- Rollenpruefung erfolgt serverseitig
+
+#### 6.7 Chat-Kanalstruktur
+
+Pro Praxis:
+1. **Allgemein** – Standard-Kanal, alle Benutzer
+2. **Empfang** – Empfangspersonal
+3. **Aerzte** – Nur Aerzte
+4. **MPA** – Medizinische Praxisassistenz
+5. **Labor** – Falls vorhanden
+6. **Administration** – Praxisleitung / Verwaltung
+7. **Direktchats** – 1:1 zwischen zwei Benutzern
+
+Spaeter: Externe Praxis-Verbindungen per Einladungscode.
+KEINE globale offene Benutzerliste ueber alle Praxen.
+
+#### 6.8 Aufgaben als erstklassiges Objekt
+
+Aufgaben sind NICHT nur lokale To-do-Listen, sondern server-seitige Objekte:
+
+| Feld | Typ | Beschreibung |
+|---|---|---|
+| `task_id` | UUID | Eindeutige Aufgaben-ID |
+| `practice_id` | UUID | Praxis-Scope |
+| `created_by` | user_id | Ersteller |
+| `assigned_to_user_id` | user_id | Zugewiesen an Benutzer |
+| `assigned_to_role` | string | Oder zugewiesen an Rolle |
+| `channel_id` | UUID | Zugehoeriger Kanal (optional) |
+| `status` | enum | open / in_progress / done / cancelled |
+| `due_at` | timestamp | Faelligkeitsdatum (optional) |
+| `attachments` | list | Angehaengte Dateien |
+| `audit_log` | list | Aenderungsprotokoll |
+
+Browser, Haupt-App und spaeter Mobile sehen dieselbe Aufgabenbasis.
+
+#### 6.9 Sicherheitsbasis
+
+**Pflicht:**
+- Praxis-Mandanten-Trennung (practice_id in JEDER Abfrage)
+- Serverseitige Rollenpruefung (NICHT clientseitig)
+- Geraetebindung (device_id + Vertrauensstatus)
+- Admin-Geraeteverwaltung (erlauben/sperren/loeschen)
+- Audit-Log fuer sicherheitsrelevante Aktionen
+- Session-Timeout (konfigurierbar)
+- KEINE Trennung nur ueber Benutzernamen
+- Uploads / Dateien praxisgebunden (practice_id)
+- KEINE globale Benutzerliste ueber Praxen
+
+**Sehr sinnvoll (Phase 2/3):**
+- 2FA fuer Practice Admin
+- Invite-Links mit Ablauf
+- Letzte Aktivitaet pro Benutzer/Geraet
+- Remote-Logout / Geraet sperren
+- Verschluesselte Nachrichtenspeicherung
+
+#### 6.10 Mobile-Strategie
+
+Kurzfristig: Browser + Desktop stabil.
+Mittelfristig: Echte Mobile-App fuer iPhone / Android (NICHT nur Browser).
+Spaeter: Apple Watch / Wearable NUR fuer leichte Funktionen (Benachrichtigung,
+kurze Antworten, kein voller Hauptclient).
+
+Festlegung: Mobile spaeter lieber als echte App, nicht als dauerhafte Browser-Notloesung.
+
+#### 6.11 Aktueller Stand vs. Zielarchitektur
+
+**Was schon da ist (V1):**
+- Benutzer-Sync via Backend (`empfang_users.json`)
+- Thread-basierter Chat (thread_id, reply_to)
+- Aufgaben-Panel (localStorage, user-scoped)
+- 3-Panel-Layout im Browser-Empfang
+- Ton-/Benachrichtigungssystem
+- Empfangs-Desktop-Huelle
+
+**Was noch fehlt fuer V2:**
+- practice_id in allen Entitaeten
+- Echte Authentifizierung (JWT/Session)
+- Serverseitige Kanalstruktur
+- Serverseitige Aufgaben (statt localStorage)
+- Geraeteverwaltung fuer Praxis-Admin
+- QR-Code-Kopplung fuer Mobile
+- Audit-Log
+
+#### 6.12 Umsetzungsphasen
+
+**Phase 1 (kurzfristig – aktuell):**
+Frontend-Layout, Benutzer-Sync, Chat-Threads. Kein Backend-Umbau.
+Einzelpraxis-Betrieb reicht. practice_id wird als Konzept vorbereitet,
+aber noch nicht erzwungen.
+
+**Phase 2 (mittelfristig):**
+Backend: practice_id + user_id + JWT-Auth einfuehren. Kanalstruktur serverseitig.
+Aufgaben serverseitig. Geraeteverwaltung. Admin-Panel fuer Practice Admin.
+Presence/Heartbeat. Invite-Links.
+
+**Phase 3 (spaeter):**
+Multi-Tenant produktiv (mehrere Praxen). WebSocket statt Polling. Mobile-App.
+QR-Code-Kopplung. 2FA. Verschluesselte Speicherung. Externe Praxis-Verbindungen.
 
 ---