27b1057cd4
Rapport ist jetzt dual: lokal (wie bisher) ODER Cloud auf eigenem Supabase-Server. Beide Modi haben dieselben Funktionen, Cloud zusätzlich Multi-User + Live-Sync. Storage-Architektur - src/storage/adapter.js: einheitliche Promise-API, LocalStorage- und SupabaseAdapter - src/storage/migrations.js: applyMigrations als reine Funktion, für beide Backends - Konfig-driven: VITE_SUPABASE_URL im Production-Build → automatisch Cloud-Modus Postgres-Schema (supabase/migrations/0001–0010) - 29 Tabellen, multi-tenant via studio_id + Row-Level-Security - Audit-Spalten (created_by/updated_by/at) + Trigger - Seed-Trigger pro neuem Studio (Rollen, Templates, Absenz-Typen) - Realtime-Publication für Live-Sync - RPCs: ensure_profile, create_studio_with_admin (mit Personen-Sharing), list_studios, load_persons_for_studio, attach_user_to_studio Cloud-Features (App) - BackendChoice.jsx als Erst-Screen «Lokal oder Cloud» - CloudSetup.jsx: 3-Schritt-Wizard für Erst-Einrichtung - Login.jsx: Modus-Switcher + Server-URL + Studio-Dropdown + Passwort-Vergessen - ResetPassword.jsx: empfängt Mail-Link-Klick via PASSWORD_RECOVERY-Event - Realtime: Änderungen zwischen Browsern ohne Reload sichtbar - Settings → System: Cloud-Verbindung, Studio-Switcher, weiteres Studio anlegen - Settings → Team: Mitarbeiter via Email einladen (Admin-Aktion) - Personen-Sharing: bei neuem Studio Personen aus anderen Studios übernehmen - Reload-Resume: studio_id in sessionStorage, kein erneuter Login nötig Web-Deploy - deploy/docker-compose.yml + nginx.conf: dist/ via nginx-Container, Port 8080 - .env.production.example: Build-time Cloud-URL - DEPLOY.md: Anleitung für LAN-only und extern via Nginx Proxy Manager Doku - README.md: Cloud-Variante prominent erklärt - ARCHITECTURE.md: Storage-Adapter, Migrations, neue Views in Risiko-Tabelle - DEPLOY.md: Schritt-für-Schritt für Mac Mini + NPM Version-Bump auf 0.8.0 in package.json, src-tauri/tauri.conf.json, Cargo.toml. Changelog-Entry im App.jsx-Modal (Karim sieht ihn beim ersten Start). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
29 lines
1.3 KiB
PL/PgSQL
29 lines
1.3 KiB
PL/PgSQL
-- ============================================================================
|
|
-- RAPPORT — Public Studio-Liste für Login-Dropdown
|
|
-- ============================================================================
|
|
-- Wenn auf einer Supabase-Instanz mehrere Firmen / Studios gehostet sind,
|
|
-- soll der Login-Screen vor Email+Passwort einen Dropdown zeigen: «In welches
|
|
-- Studio möchten Sie sich einloggen?». Dafür braucht das Frontend eine Liste
|
|
-- aller Studios — ohne dass jemand bereits eingeloggt sein muss.
|
|
--
|
|
-- RLS verhindert das normalerweise (`studios_member_access` nur für Member).
|
|
-- Diese SECURITY-DEFINER-Funktion umgeht RLS und liefert nur die öffentlichen
|
|
-- Identitäts-Felder (name, slug). Keine Tenant-Daten, kein Risiko.
|
|
--
|
|
-- Trade-Off: Studio-Namen sind in dem Sinne «öffentlich» — wer die Server-URL
|
|
-- kennt, kann sehen welche Firmen hier hosten. Bei einem Selfhosted-Setup für
|
|
-- 1-3 befreundete Studios ist das akzeptabel; bei einer Public-SaaS-Instanz
|
|
-- wäre das ein Re-Design wert.
|
|
-- ============================================================================
|
|
|
|
create or replace function list_studios()
|
|
returns table(id uuid, name text, slug text)
|
|
language sql
|
|
security definer
|
|
stable
|
|
as $$
|
|
select id, name, slug from studios order by name;
|
|
$$;
|
|
|
|
grant execute on function list_studios() to anon, authenticated;
|