@fayz-ai/db 0.9.0-next.0 → 0.9.0

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,7 +3,7 @@
   "fayz": {
     "status": "beta"
   },
-  "version": "0.9.0-next.0",
+  "version": "0.9.0",
   "description": "Fayz SDK database layer — Drizzle schema primitives, spine references, and migration helpers shared across plugins.",
   "type": "module",
   "sideEffects": false,