@fayz-ai/db 0.12.0 → 0.14.0

package/migrations/013_the_workspace_switch_reaches_the_other_half.sql

@@ -0,0 +1,156 @@
+-- ---------------------------------------------------------------------------
+-- 013_the_workspace_switch_reaches_the_other_half.sql — the unit dropdown
+-- stops listing other people's businesses.
+--
+-- THE BUG, as seen: the "Unidade" filter and the "Selecionar local…" picker in
+-- a beauty account offered Américas Shopping, Depósito Central, Papa Léguas
+-- Tacos and Mesa 1 — units belonging to eight OTHER tenants. Picking one wrote
+-- a foreign unit id onto a booking. This is a tenant boundary failure, not a
+-- filter that forgot a WHERE.
+--
+-- THE CAUSE, and it is one sentence: the database has TWO ideas of "my tenant"
+-- and only one of them can hear the workspace switch.
+--
+--   app.current_tenant_id()  — signed JWT claim, else the `x-fayz-tenant`
+--                              header the client sends, else "your only
+--                              account". This is the ACTIVE workspace.
+--   public.user_tenant_ids() — every account you belong to. It reads the JWT
+--   app.is_member(tenant)      claim but has never read the HEADER, and nobody
+--                              mints a claim.
+--
+-- 145 added `x-fayz-tenant` so a two-account user could read public.people /
+-- orders / products at all — those policies were already on current_tenant_id()
+-- and were returning NOTHING. The other half of the schema was left on
+-- user_tenant_ids(), where the same header is invisible. So the switch narrows
+-- one half of the database and the other half keeps answering for all of them
+-- at once: 133 tables, every plugin, plus app.units, app.roles and
+-- app.role_permissions.
+--
+-- Nobody saw it on a single-account tenant, which is every real customer today
+-- and every QA login but one. It is visible the moment somebody has two.
+--
+-- THE FIX: user_tenant_ids() means the ACTIVE workspace, like everything else.
+-- The one caller that genuinely wants "every account of mine" — the app
+-- switcher, whose whole job (008) is to reach across accounts — says so out
+-- loud, through a function with that name.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  "my tenant" means one tenant ───────────────────────────────────────
+--
+-- Delegating rather than re-deriving: the claim/header/single-account ladder is
+-- subtle (a header pointing at an account that is not yours must DENY, not fall
+-- back), it already exists in current_tenant_id, and two copies of it would be
+-- two chances to disagree about who you are.
+
+CREATE OR REPLACE FUNCTION public.user_tenant_ids() RETURNS SETOF uuid
+    LANGUAGE sql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+  SELECT t.id FROM (SELECT app.current_tenant_id() AS id) t WHERE t.id IS NOT NULL;
+$$;
+
+COMMENT ON FUNCTION public.user_tenant_ids() IS
+  'The ACTIVE workspace, as a set, for the ~130 policies written as `tenant_id IN (SELECT user_tenant_ids())` (013). It used to mean "every account I belong to", which made the workspace switch invisible to every table that used it. Cross-account readers want user_all_tenant_ids() and must say so.';
+
+-- Admin rights are read the same way: which accounts you administer is not the
+-- question a policy on THIS account's row is asking.
+CREATE OR REPLACE FUNCTION public.user_admin_tenant_ids() RETURNS SETOF uuid
+    LANGUAGE sql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+  SELECT m.tenant_id
+    FROM app.memberships m
+    JOIN app.roles r ON r.id = m.role_id
+   WHERE m.user_id = auth.uid() AND m.active
+     AND m.tenant_id = app.current_tenant_id()
+     AND r.key IN ('owner', 'admin');
+$$;
+
+COMMENT ON FUNCTION public.user_admin_tenant_ids() IS
+  'Whether you administer the ACTIVE workspace, as a set (013). Narrowed for the same reason as user_tenant_ids: being an owner somewhere else is not permission here.';
+
+-- ── §2  the switcher asks its own question ─────────────────────────────────
+
+CREATE OR REPLACE FUNCTION public.user_all_tenant_ids() RETURNS SETOF uuid
+    LANGUAGE sql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+  SELECT m.tenant_id FROM app.memberships m
+   WHERE m.user_id = auth.uid() AND m.active;
+$$;
+
+COMMENT ON FUNCTION public.user_all_tenant_ids() IS
+  'Every account the caller belongs to (013). For the app/workspace switcher ONLY — the one screen whose question is "which of my accounts", asked before an account is chosen. A policy that reaches for this is claiming to be cross-account; almost none should be.';
+
+REVOKE ALL ON FUNCTION public.user_all_tenant_ids() FROM PUBLIC;
+GRANT EXECUTE ON FUNCTION public.user_all_tenant_ids() TO authenticated, service_role;
+
+-- app.tenant_apps is that screen's table: v_tenant_apps (008) lists which of
+-- MY accounts run the app I am looking at, and that list is drawn before the
+-- account is picked. Narrowing it would leave the switcher with one row.
+DROP POLICY IF EXISTS tenant_apps_read ON app.tenant_apps;
+CREATE POLICY tenant_apps_read ON app.tenant_apps FOR SELECT TO authenticated
+  USING (tenant_id IN (SELECT public.user_all_tenant_ids()));
+
+-- ── §3  the four app.* reads still on "any account of mine" ────────────────
+--
+-- Their siblings (units_insert/update/delete, roles_update, …) already compare
+-- to current_tenant_id(). Only the SELECT was written with is_member, which is
+-- why writing was scoped and READING was not.
+
+DROP POLICY IF EXISTS units_select ON app.units;
+CREATE POLICY units_select ON app.units FOR SELECT TO authenticated
+  USING (tenant_id = (SELECT app.current_tenant_id()));
+
+DROP POLICY IF EXISTS roles_select ON app.roles;
+CREATE POLICY roles_select ON app.roles FOR SELECT TO authenticated
+  USING (tenant_id = (SELECT app.current_tenant_id()));
+
+DROP POLICY IF EXISTS role_permissions_select ON app.role_permissions;
+CREATE POLICY role_permissions_select ON app.role_permissions FOR SELECT TO authenticated
+  USING (tenant_id = (SELECT app.current_tenant_id()));
+
+DROP POLICY IF EXISTS resource_grants_select ON app.resource_grants;
+CREATE POLICY resource_grants_select ON app.resource_grants FOR SELECT TO authenticated
+  USING (tenant_id = (SELECT app.current_tenant_id()));
+
+-- ── §4  a table with no boundary at all ────────────────────────────────────
+--
+-- USING (true): which stock engine each tenant's products are counted by, plus
+-- their product ids, readable by anybody with a login to anything. 146 wrote it
+-- open on the argument that the row is "configuration"; a row keyed by
+-- tenant_id and product_id is that tenant's, whatever it holds.
+
+DROP POLICY IF EXISTS product_stock_source_read ON app.product_stock_source;
+CREATE POLICY product_stock_source_read ON app.product_stock_source FOR SELECT TO authenticated
+  USING (tenant_id = (SELECT app.current_tenant_id()));
+
+-- ── §5  the legacy role tables ─────────────────────────────────────────────
+--
+-- tenant_roles_read is older still: it joins public.tenant_members, which 007
+-- removed, so the policy is dead weight that would come back to life — wide —
+-- if anything ever recreated that name.
+
+-- Guarded: a pool that never took the permission-profiles tables has neither,
+-- and a boundary fix is not the place to demand them.
+DO $$
+BEGIN
+  IF to_regclass('public.tenant_roles') IS NOT NULL THEN
+    DROP POLICY IF EXISTS tenant_roles_read   ON public.tenant_roles;
+    DROP POLICY IF EXISTS tenant_roles_select ON public.tenant_roles;
+    CREATE POLICY tenant_roles_select ON public.tenant_roles FOR SELECT TO authenticated
+      USING (tenant_id = (SELECT app.current_tenant_id()));
+  END IF;
+
+  IF to_regclass('public.tenant_role_overrides') IS NOT NULL THEN
+    DROP POLICY IF EXISTS overrides_select ON public.tenant_role_overrides;
+    CREATE POLICY overrides_select ON public.tenant_role_overrides FOR SELECT TO authenticated
+      USING (tenant_id = (SELECT app.current_tenant_id()));
+  END IF;
+END $$;
+
+-- ── §6  the audit row is written into the account it happened in ───────────
+
+DROP POLICY IF EXISTS audit_insert ON public.audit_logs;
+CREATE POLICY audit_insert ON public.audit_logs FOR INSERT TO authenticated
+  WITH CHECK (tenant_id = (SELECT app.current_tenant_id()));

package/migrations/014_the_chooser_can_read_what_it_offers.sql

@@ -0,0 +1,91 @@
+-- ---------------------------------------------------------------------------
+-- 014_the_chooser_can_read_what_it_offers.sql — the workspace picker stops
+-- asking a question it is not allowed to hear the answer to.
+--
+-- THE BUG, as seen: an account belonging to seven workspaces signs in and the
+-- shell offers "Nova área de trabalho" — as if it belonged to none. The
+-- browser console shows the real failure a layer down:
+--
+--     TypeError: Cannot read properties of null (reading 'charAt')
+--         at capitalize (admin/src/org/adapters/supabase.ts)
+--         at async loadOrgs
+--
+-- THE CAUSE: 013 finished half a thought. It redefined user_tenant_ids() to
+-- mean the ACTIVE workspace — correct, and the fix for 133 leaking tables —
+-- and it understood that the SWITCHER is the one screen that must read across
+-- accounts, because it runs BEFORE an account is chosen. But it granted that
+-- exception to exactly one table, app.tenant_apps, and the switcher reads
+-- three:
+--
+--   app.tenant_apps  — which of my accounts run this app.   013 fixed it.
+--   public.tenants   — what those accounts are CALLED.      Still narrow.
+--   app.roles        — what I am in each of them.           Still narrow.
+--
+-- Before a choice exists current_tenant_id() is NULL, so the last two answer
+-- with nothing: v_team_members returns the seven memberships (its own table
+-- lets you see your own rows) with `tenant` null and `role` null. The client
+-- capitalises the role, hits null, throws, and the whole membership load dies
+-- with it — which is why the screen says "no workspace" rather than "seven
+-- workspaces with blank names".
+--
+-- It is a chicken-and-egg, and it is invisible on a single-workspace account:
+-- there the client's own fallback picks the only membership before anything
+-- needs a name. Every real customer today is single-workspace. Every QA login
+-- but one is too.
+--
+-- THE FIX: the two remaining reads on the pre-selection path say out loud that
+-- they are cross-account, the same way 013 made app.tenant_apps say it. This
+-- restores exactly what these two tables answered BEFORE 013 and nothing more
+-- — 013 narrowed them as collateral, not as intent; its subject was units and
+-- bookings leaking to NON-members, which neither of these ever did.
+-- ---------------------------------------------------------------------------
+
+-- ── §1  the accounts have names again ──────────────────────────────────────
+--
+-- A workspace row is readable when you are a MEMBER of that workspace — which
+-- is what the policy said until 013, and what the picker needs to draw a list
+-- you can choose from. Membership, not the active choice, is the boundary
+-- here: the rows are your own accounts either way.
+
+DROP POLICY IF EXISTS tenants_select ON public.tenants;
+CREATE POLICY tenants_select ON public.tenants FOR SELECT TO authenticated
+  USING (id IN (SELECT public.user_all_tenant_ids()));
+
+COMMENT ON POLICY tenants_select ON public.tenants IS
+  'Every workspace you belong to, named (014). Cross-account on purpose: the picker that chooses the active workspace has to render the list before one exists, so scoping this to the active choice makes the choice unmakeable.';
+
+-- ── §2  my own role travels with my own membership ─────────────────────────
+--
+-- Not the whole role TABLE of every account — 013 was right that the role list
+-- of a workspace you are not looking at is none of this request's business.
+-- The narrow thing the picker needs is one row per membership: the role I hold
+-- THERE, which v_team_members joins to turn a role_id into a key ('owner').
+--
+-- SECURITY DEFINER for the same reason the 013 helpers are: a policy
+-- expression is evaluated as the caller, and reaching into app.memberships
+-- from inside a policy that app.memberships' own policies can reach back into
+-- is how recursion starts.
+
+CREATE OR REPLACE FUNCTION public.user_own_role_ids() RETURNS SETOF uuid
+    LANGUAGE sql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $$
+  SELECT m.role_id FROM app.memberships m
+   WHERE m.user_id = auth.uid() AND m.active AND m.role_id IS NOT NULL;
+$$;
+
+COMMENT ON FUNCTION public.user_own_role_ids() IS
+  'The roles the caller personally holds, across every account they belong to (014). For the workspace picker, which shows you what you are in each — not for reading an account''s role list, which stays on the active workspace.';
+
+REVOKE ALL ON FUNCTION public.user_own_role_ids() FROM PUBLIC;
+GRANT EXECUTE ON FUNCTION public.user_own_role_ids() TO authenticated, service_role;
+
+DROP POLICY IF EXISTS roles_select ON app.roles;
+CREATE POLICY roles_select ON app.roles FOR SELECT TO authenticated
+  USING (
+    tenant_id = (SELECT app.current_tenant_id())
+    OR id IN (SELECT public.user_own_role_ids())
+  );
+
+COMMENT ON POLICY roles_select ON app.roles IS
+  'The active workspace''s roles (013), plus the caller''s OWN role in each account they belong to (014) — the second clause is what lets the workspace picker say "Owner" next to a workspace you have not entered yet.';

package/migrations/015_the_unit_bindings_belong_to_one_workspace.sql

@@ -0,0 +1,86 @@
+-- ---------------------------------------------------------------------------
+-- 015_the_unit_bindings_belong_to_one_workspace.sql — the Unidades menu stops
+-- going blank in the workspace you are actually standing in.
+--
+-- THE BUG, as seen: "Espaço Facial não lista as unidades". The account has four
+-- ACTIVE units in that workspace and the menu drew its "Unidades" heading with
+-- nothing underneath it.
+--
+-- THE CAUSE: `unit_bootstrap` filters every clause it has by p_tenant_id — the
+-- units, the scoping mode, both pins — except one:
+--
+--     'bindings', ( SELECT ... FROM public.v_unit_members lm
+--                    WHERE lm.user_id = auth.uid() )        -- and nothing else
+--
+-- RLS does not save it. `membership_units_select` lets you read your OWN rows
+-- unconditionally (`user_id = auth.uid() OR ...`) — it has to, or you could not
+-- find yourself — and "your own rows" spans every account you belong to. So the
+-- call returned a binding to `Ideale 633`, a unit of Espaco Renova Rio, while
+-- the caller was standing in Espaço Facial.
+--
+-- The client then does the reasonable thing with an unreasonable answer.
+-- UnitMenuSection narrows the list to what you are bound to:
+--
+--     reachable = myUnitIds.length > 0 ? myUnitIds : <every unit>
+--
+-- One foreign binding is enough to take the first branch, and no unit of THIS
+-- tenant is in it. Not an empty list — a list of somewhere else. The fallback
+-- that would have shown all four units never runs.
+--
+-- Invisible on a single-workspace account, like everything else in this family:
+-- there, every binding you have is in the only tenant you are in.
+--
+-- THE FIX: the one clause that forgot says which workspace it means, like its
+-- four siblings in the same function.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION public.unit_bootstrap(p_tenant_id uuid, p_device_id text DEFAULT NULL::text)
+ RETURNS jsonb
+ LANGUAGE sql
+ STABLE
+ SET search_path TO 'public', 'pg_temp'
+AS $function$
+  SELECT jsonb_build_object(
+    'mode', COALESCE((
+      SELECT t.unit_scoping_enabled FROM public.tenants t WHERE t.id = p_tenant_id
+    ), false),
+    'units', COALESCE((
+      SELECT jsonb_agg(to_jsonb(l) ORDER BY l.is_headquarters DESC NULLS LAST, l.name)
+        FROM public.v_units l WHERE l.tenant_id = p_tenant_id
+    ), '[]'::jsonb),
+    -- The tenant filter (015). Without it a binding from another workspace
+    -- comes back here and the switcher narrows to a unit this tenant does not
+    -- have, which reads on screen as "this account has no units".
+    'bindings', COALESCE((
+      SELECT jsonb_agg(jsonb_build_object('location_id', lm.location_id, 'role', lm.role))
+        FROM public.v_unit_members lm
+       WHERE lm.user_id = (SELECT auth.uid())
+         AND lm.tenant_id = p_tenant_id
+    ), '[]'::jsonb),
+    'scoped', COALESCE((
+      SELECT jsonb_object_agg(sr.resource_table, jsonb_build_object(
+               'unit_column', sr.unit_column, 'shareable', sr.shareable))
+        FROM public.scoped_resources sr
+    ), '{}'::jsonb),
+    'device_pin', (
+      SELECT p.unit_id FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid()) AND p.tenant_id = p_tenant_id AND p.device_id = p_device_id
+    ),
+    'device_pin_set', EXISTS (
+      SELECT 1 FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid()) AND p.tenant_id = p_tenant_id AND p.device_id = p_device_id
+    ),
+    'account_pin', (
+      SELECT p.unit_id FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid()) AND p.tenant_id = p_tenant_id
+       ORDER BY p.updated_at DESC LIMIT 1
+    ),
+    'account_pin_set', EXISTS (
+      SELECT 1 FROM public.user_unit_prefs p
+       WHERE p.user_id = (SELECT auth.uid()) AND p.tenant_id = p_tenant_id
+    )
+  );
+$function$;
+
+COMMENT ON FUNCTION public.unit_bootstrap(uuid, text) IS
+  'Everything the unit switcher needs for ONE workspace, in one round trip. Every clause is scoped to p_tenant_id — including bindings, which was not, and leaked a unit of another account into this one''s menu (015).';