@fayz-ai/db 0.8.4 → 0.9.0-next.1

package/migrations/021_tenant_roles.sql

@@ -0,0 +1,74 @@
+-- ============================================================================
+-- 021_tenant_roles.sql — custom access profiles, per tenant.
+--
+-- The SDK has always been able to BUILD a custom role (duplicate a system role
+-- in Settings → Permissions, or ask the assistant for one), but the table it
+-- writes to never existed outside one legacy pool: `saas_core.tenant_roles`,
+-- swept into `public` by 0000b and created nowhere else. Everywhere else the
+-- insert threw and the screen swallowed it — a "Criar perfil" button that did
+-- nothing.
+--
+-- Two changes, both required for a custom profile to survive a reload:
+--
+--   1. public.tenant_roles — the role's IDENTITY (key + name). Its grants live
+--      in tenant_role_overrides, keyed by that same `key`.
+--
+--   2. tenant_role_overrides.permission_id loses its FK to public.permissions.
+--      That catalog is a legacy of DB-driven RBAC; the feature catalog is now
+--      DECLARED IN CODE by plugins (`declaredFeatures`) and merged at runtime,
+--      so an app can grant `crm.leads.read` on a pool whose permissions table
+--      never heard of plugin-crm. The FK made every such grant fail. The column
+--      stays text in `feature.action` form — the shape agent_guard reads.
+--
+-- Idempotent: safe to re-run, no-ops when already applied.
+-- ============================================================================
+
+CREATE TABLE IF NOT EXISTS public.tenant_roles (
+  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+  tenant_id uuid NOT NULL REFERENCES public.tenants(id) ON DELETE CASCADE,
+  -- Stable slug the grants and tenant_members.role point at. Renaming the
+  -- profile must never orphan its permissions, so the key is not the name.
+  key text NOT NULL,
+  name text NOT NULL,
+  description text,
+  created_at timestamptz NOT NULL DEFAULT now(),
+  UNIQUE(tenant_id, key)
+);
+
+ALTER TABLE public.tenant_roles ENABLE ROW LEVEL SECURITY;
+
+-- Members see their own tenant's roles (the permission screen lists them);
+-- only tenant admins create, rename or delete one.
+DROP POLICY IF EXISTS "tenant_roles_select" ON public.tenant_roles;
+CREATE POLICY "tenant_roles_select" ON public.tenant_roles FOR SELECT
+  USING (tenant_id IN (SELECT tenant_id FROM public.tenant_members WHERE user_id = auth.uid()));
+
+DROP POLICY IF EXISTS "tenant_roles_manage" ON public.tenant_roles;
+CREATE POLICY "tenant_roles_manage" ON public.tenant_roles FOR ALL
+  USING (public.is_tenant_admin(tenant_id));
+
+GRANT ALL ON public.tenant_roles TO authenticated, service_role;
+
+-- The FK, dropped by lookup rather than by name: pools created before the
+-- rename carry the constraint under whatever name Postgres minted.
+DO $$
+DECLARE
+  c record;
+BEGIN
+  IF to_regclass('public.tenant_role_overrides') IS NULL THEN
+    RETURN;
+  END IF;
+  FOR c IN
+    SELECT con.conname
+    FROM pg_constraint con
+    JOIN pg_class rel ON rel.oid = con.conrelid
+    JOIN pg_namespace nsp ON nsp.oid = rel.relnamespace
+    JOIN pg_class frel ON frel.oid = con.confrelid
+    WHERE nsp.nspname = 'public'
+      AND rel.relname = 'tenant_role_overrides'
+      AND con.contype = 'f'
+      AND frel.relname = 'permissions'
+  LOOP
+    EXECUTE format('ALTER TABLE public.tenant_role_overrides DROP CONSTRAINT %I', c.conname);
+  END LOOP;
+END $$;

package/migrations/022_invite_acceptance.sql

@@ -0,0 +1,91 @@
+-- ============================================================================
+-- 022_invite_acceptance.sql — o convite finalmente vira membro da org.
+--
+-- `createInvite` sempre gravou a linha em `invitations` e mandou o magic link,
+-- mas NADA nunca converteu essa linha em `tenant_members`. O convidado entrava,
+-- `listUserOrgs` voltava vazio, e o autoCreate do OrgProvider (ligado por
+-- padrão) criava uma "My Organization" nova com role `owner` — a org que
+-- convidou caía no chão em silêncio.
+--
+-- Duas mudanças:
+--
+--   1. public.accept_pending_invitations() — o resgate que faltava. O client
+--      chama logo depois do sign-in, antes de listar as orgs.
+--
+--      A fonte é a linha de `invitations`, NÃO `auth.users.raw_user_meta_data`.
+--      O metadata também carrega tenant_id/role, mas vem de um
+--      `signInWithOtp({ data })` do browser — qualquer um com a anon key se
+--      carimbaria dentro de qualquer tenant. `invitations` é RLS-gated a admin
+--      do tenant, então é o único sinal confiável.
+--
+--   2. `invites_select` deixa de ser `USING (true)`. Num pool de indústria
+--      compartilhado isso deixava qualquer usuário autenticado ler a lista de
+--      convites de todos os tenants — e-mails inclusive. Agora: os seus
+--      tenants, mais os convites endereçados a você (que o resgate precisa ver).
+--
+-- Idempotente: seguro re-rodar, no-op quando já aplicada.
+-- ============================================================================
+
+CREATE OR REPLACE FUNCTION public.accept_pending_invitations()
+RETURNS integer
+LANGUAGE plpgsql
+SECURITY DEFINER
+SET search_path = public
+AS $$
+DECLARE
+  v_uid uuid := auth.uid();
+  v_email text;
+  v_count integer := 0;
+  r record;
+BEGIN
+  IF v_uid IS NULL THEN
+    RETURN 0;
+  END IF;
+
+  -- Lido de auth.users, não do JWT: sobrevive a token sem claim de e-mail.
+  SELECT u.email INTO v_email FROM auth.users u WHERE u.id = v_uid;
+  IF v_email IS NULL OR v_email = '' THEN
+    RETURN 0;
+  END IF;
+
+  FOR r IN
+    SELECT i.id, i.tenant_id, i.role, i.location_ids
+    FROM public.invitations i
+    WHERE lower(i.email) = lower(v_email)
+      AND i.status = 'pending'
+      AND i.expires_at > now()
+    ORDER BY i.created_at
+  LOOP
+    -- DO NOTHING e não DO UPDATE: um convite nunca troca o papel de quem já é membro.
+    INSERT INTO public.tenant_members (tenant_id, user_id, role)
+    VALUES (r.tenant_id, v_uid, r.role)
+    ON CONFLICT (tenant_id, user_id) DO NOTHING;
+
+    IF r.location_ids IS NOT NULL AND array_length(r.location_ids, 1) > 0 THEN
+      INSERT INTO public.location_members (location_id, user_id, role)
+      SELECT l.id, v_uid, r.role
+      FROM public.locations l
+      WHERE l.id = ANY(r.location_ids) AND l.tenant_id = r.tenant_id
+      ON CONFLICT (location_id, user_id) DO NOTHING;
+    END IF;
+
+    UPDATE public.invitations
+    SET status = 'accepted', accepted_at = now()
+    WHERE id = r.id;
+
+    v_count := v_count + 1;
+  END LOOP;
+
+  RETURN v_count;
+END; $$;
+
+REVOKE ALL ON FUNCTION public.accept_pending_invitations() FROM public;
+REVOKE ALL ON FUNCTION public.accept_pending_invitations() FROM anon;
+GRANT EXECUTE ON FUNCTION public.accept_pending_invitations() TO authenticated, service_role;
+
+DROP POLICY IF EXISTS "invites_select" ON public.invitations;
+CREATE POLICY "invites_select" ON public.invitations FOR SELECT TO authenticated
+  USING (
+    tenant_id IN (SELECT public.user_tenant_ids())
+    OR lower(email) = lower(coalesce(auth.jwt() ->> 'email', ''))
+  );

package/migrations/023_team_visibility.sql

@@ -0,0 +1,75 @@
+-- ============================================================================
+-- 023_team_visibility.sql — a equipe finalmente enxerga a equipe.
+--
+-- `001_core` fechou dois SELECTs no próprio usuário:
+--
+--     profiles_select   USING (id = auth.uid())        -- "own profile only"
+--     members_select    USING (user_id = auth.uid())   -- "see own"
+--
+-- Com isso a tela de Equipe é impossível por construção: nenhum usuário, em
+-- nenhum tenant, jamais vê mais de um membro. O sintoma muda com o modo da
+-- TeamTab, mas a causa é a mesma:
+--
+--   • modo legado (lista vem de `listMembers` → tenant_members): "1 membro
+--     nesta organização", sempre — só a própria linha atravessa a RLS.
+--
+--   • person-mode (lista vem de `people`, com o vínculo sobreposto a partir de
+--     tenant_members): as pessoas aparecem, mas `p.membership` volta undefined
+--     para todo mundo menos você → `hasAccess = false` → a linha exibe
+--     "sem acesso" + botão Convidar MESMO para quem já tem conta e papel.
+--     Quem tem acesso e quem não tem ficam indistinguíveis na tela.
+--
+-- Não é decisão de projeto que valha manter: o resto do próprio 001_core já
+-- usa o padrão tenant-wide (`subs_select`, `invoices_select`,
+-- `loc_members_select` todos fazem tenant_id IN (... WHERE user_id = auth.uid())).
+-- Só members/profiles ficaram no `= auth.uid()`. Esta migration alinha os dois
+-- com o padrão que o core já adota — não inventa política nova.
+--
+-- O alcance é deliberadamente o mínimo que a tela precisa: quem divide tenant
+-- com você passa a ver seu nome, e-mail e avatar. Nada atravessa tenant.
+--
+-- EFEITO COLATERAL ESPERADO — seat cap. O limite 'users'
+-- (limits-registry.ts → { key: 'users', table: 'tenant_members' }) conta linhas
+-- de tenant_members, e hoje essa contagem volta 1 para todo mundo: o cap de
+-- assentos nunca foi de fato aplicado. Depois desta migration ele passa a
+-- contar certo, e tenants acima do plano vão bater no UpgradeModal ao convidar.
+-- É a regra funcionando pela primeira vez, não uma regressão — mas conferir os
+-- planos antes de aplicar em produção evita susto.
+--
+-- Idempotente: seguro re-rodar, no-op quando já aplicada.
+-- ============================================================================
+
+-- Os membros dos SEUS tenants, não só você.
+--
+-- `user_tenant_ids()` (002) é SECURITY DEFINER, então roda por fora da RLS e a
+-- policy de tenant_members pode consultar tenant_members sem recursão. Trocar
+-- por um EXISTS inline sobre a mesma tabela reintroduz o loop — não simplifique.
+DROP POLICY IF EXISTS "members_select" ON public.tenant_members;
+CREATE POLICY "members_select" ON public.tenant_members FOR SELECT TO authenticated
+  USING (tenant_id IN (SELECT public.user_tenant_ids()));
+
+-- O profile de quem divide tenant com você. Mesmo motivo do SECURITY DEFINER
+-- acima: a checagem lê tenant_members, que agora tem policy própria.
+CREATE OR REPLACE FUNCTION public.shares_tenant_with(p_user_id uuid)
+RETURNS boolean
+LANGUAGE sql
+STABLE
+SECURITY DEFINER
+SET search_path = public
+AS $$
+  SELECT EXISTS (
+    SELECT 1
+    FROM public.tenant_members mine
+    JOIN public.tenant_members theirs ON theirs.tenant_id = mine.tenant_id
+    WHERE mine.user_id = auth.uid()
+      AND theirs.user_id = p_user_id
+  );
+$$;
+
+REVOKE ALL ON FUNCTION public.shares_tenant_with(uuid) FROM public;
+REVOKE ALL ON FUNCTION public.shares_tenant_with(uuid) FROM anon;
+GRANT EXECUTE ON FUNCTION public.shares_tenant_with(uuid) TO authenticated, service_role;
+
+DROP POLICY IF EXISTS "profiles_select" ON public.profiles;
+CREATE POLICY "profiles_select" ON public.profiles FOR SELECT TO authenticated
+  USING (id = auth.uid() OR public.shares_tenant_with(id));

package/package.json

@@ -3,9 +3,10 @@
   "fayz": {
     "status": "beta"
   },
-  "version": "0.8.4",
+  "version": "0.9.0-next.1",
   "description": "Fayz SDK database layer — Drizzle schema primitives, spine references, and migration helpers shared across plugins.",
   "type": "module",
+  "sideEffects": false,
   "main": "./dist/index.cjs",
   "module": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -37,6 +38,7 @@
     "database",
     "schema"
   ],
+  "peerDependencies": {},
   "scripts": {
     "build": "tsup && tsc --emitDeclarationOnly --declaration --declarationMap --noEmit false",
     "dev": "tsup --watch",