26 lines
1.3 KiB
SQL
26 lines
1.3 KiB
SQL
-- H2: Sichtbarkeits-Flags auf DB-Ebene durchsetzen.
|
|
--
|
|
-- phone_mobile, linkedin_url und xing_url waren spaltenweise an anon
|
|
-- GRANTed (Migration 0014 ff.). Die Opt-out-Flags show_mobile/show_linkedin/
|
|
-- show_xing filterten diese Felder aber NUR in der Render-Schicht
|
|
-- (VisitingCard) und im vCard-Builder — über den öffentlichen anon-Key
|
|
-- liessen sie sich per Supabase-REST direkt für ALLE aktiven Mitarbeiter
|
|
-- abgreifen, unabhaengig vom Opt-out. Das ist dieselbe Klasse wie K-1:
|
|
-- RLS-Policies und Grants filtern KEINE Spalten bedingt.
|
|
--
|
|
-- Ab jetzt liest die App diese Felder ausschliesslich serverseitig ueber
|
|
-- getActiveEmployeeBySlug (auf createServiceClient umgestellt) und wendet
|
|
-- die show_*-Flags weiterhin im Server-Render/vCard an. anon braucht die
|
|
-- Felder daher nicht mehr.
|
|
--
|
|
-- successor_employee_id / successor_note werden ohnehin nur ueber
|
|
-- getSuccessorInfoForSlug (service-role) gelesen und sind hier mit
|
|
-- abgeraeumt (vorher unnoetig anon-lesbar, Low-Befund).
|
|
--
|
|
-- REVOKE auf nicht vorhandene Spalten-Grants ist ein No-op (NOTICE, kein
|
|
-- Fehler) — die Migration ist damit auch auf Instanzen ohne den vollen
|
|
-- Grant unkritisch.
|
|
|
|
revoke select (phone_mobile, linkedin_url, xing_url, successor_employee_id, successor_note)
|
|
on public.employees from anon;
|