@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/112_o_cache_do_contexto_sabe_de_quem_ele_e.sql

@@ -0,0 +1,327 @@
+-- O cache do contexto sabe de quem ele é
+--
+-- A 076 passou a calcular o contexto da requisição UMA vez por transação, e
+-- está certa no motivo: contar um mês de agenda pagava 2,7 ms por linha para
+-- reconfirmar a mesma resposta. O que ela não fez foi dizer de QUEM é a
+-- resposta guardada.
+--
+--     DECLARE v_cache text := current_setting('app.ctx_tenant', true);
+--     IF v_cache IS NOT NULL AND v_cache <> '' THEN
+--       RETURN nullif(v_cache, '-')::uuid;   -- <- de quem?
+--
+-- `set_config(..., true)` é local à TRANSAÇÃO, não à requisição. Enquanto a
+-- claim não muda dentro da transação, as duas coisas coincidem e ninguém nota.
+-- Quando ela muda, o cache responde pelo dono anterior.
+--
+-- ── Onde isso aparece ───────────────────────────────────────────────────────
+--
+-- O pgTAP troca de persona dentro de uma transação só — é o jeito de provar
+-- justamente as regras que esta função implementa. Trinta e sete suítes
+-- quebraram de uma vez, todas na mesma frase:
+--
+--     "a claim naming another tenant resolves to no tenant"
+--       have: 3fc8bcfd-…   (o salão, do teste anterior)
+--       want: NULL
+--
+-- O teste não estava errado. A função é que respondia pela persona passada.
+--
+-- Em produção o PostgREST abre uma transação por requisição e a claim não muda
+-- no meio, então o furo não aparece — mas ele existe para qualquer caminho que
+-- troque de sujeito dentro de uma transação, e o primeiro que fizer isso vai
+-- receber a resposta de outra pessoa sem nenhum aviso.
+--
+-- ── O conserto ──────────────────────────────────────────────────────────────
+--
+-- Guardar, junto do valor, a CHAVE de quem o produziu, e só aceitar o cache
+-- quando a chave é a mesma. A chave é a própria claim: `auth.uid()` e
+-- `auth.jwt()` saem ambos de `request.jwt.claims`, então ela cobre todas as
+-- entradas da regra crua. Para a unidade entra também o cabeçalho, que é de
+-- onde `x-fayz-unit` vem.
+--
+-- O ganho da 076 fica de pé: dentro de uma requisição real a chave não muda, o
+-- cache acerta toda vez, e a regra crua continua rodando uma vez só. O que
+-- muda é que agora ele sabe quando não é dele que estão falando.
+--
+-- A regra em si não é tocada: `app._current_tenant_id_raw()` continua igual.
+-- Idempotente.
+
+CREATE OR REPLACE FUNCTION app.current_tenant_id()
+ RETURNS uuid
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  -- As DUAS grafias: `auth.uid()` le `request.jwt.claim.sub` e, se nao houver,
+  -- o `sub` de dentro de `request.jwt.claims`. Uma chave que olhasse so a
+  -- segunda nao veria a troca de pessoa feita pela primeira — que e como o
+  -- pgTAP e o codigo mais antigo trocam de sujeito.
+  v_key   text := coalesce(current_setting('request.jwt.claims', true), '')
+                  || '|' || coalesce(current_setting('request.jwt.claim.sub', true), '');
+  v_cache text := current_setting('app.ctx_tenant', true);
+  v_owner text := current_setting('app.ctx_tenant_key', true);
+  v_out   uuid;
+BEGIN
+  IF v_cache IS NOT NULL AND v_cache <> '' AND v_owner IS NOT DISTINCT FROM v_key THEN
+    RETURN nullif(v_cache, '-')::uuid;
+  END IF;
+  v_out := app._current_tenant_id_raw();
+  PERFORM set_config('app.ctx_tenant', coalesce(v_out::text, '-'), true);
+  PERFORM set_config('app.ctx_tenant_key', v_key, true);
+  RETURN v_out;
+END $function$;
+
+CREATE OR REPLACE FUNCTION app.current_unit_id()
+ RETURNS uuid
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  -- A unidade depende de quem pergunta E do cabeçalho que ele mandou.
+  v_key   text := coalesce(current_setting('request.jwt.claims', true), '')
+                  || '|' || coalesce(current_setting('request.jwt.claim.sub', true), '')
+                  || '|' || coalesce(current_setting('request.headers', true), '');
+  v_cache text := current_setting('app.ctx_unit', true);
+  v_owner text := current_setting('app.ctx_unit_key', true);
+  v_out   uuid;
+BEGIN
+  IF v_cache IS NOT NULL AND v_cache <> '' AND v_owner IS NOT DISTINCT FROM v_key THEN
+    RETURN nullif(v_cache, '-')::uuid;
+  END IF;
+  v_out := app._current_unit_id_raw();
+  PERFORM set_config('app.ctx_unit', coalesce(v_out::text, '-'), true);
+  PERFORM set_config('app.ctx_unit_key', v_key, true);
+  RETURN v_out;
+END $function$;
+
+CREATE OR REPLACE FUNCTION app.unit_scoping_on()
+ RETURNS boolean
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_key   text := coalesce(current_setting('request.jwt.claims', true), '')
+                  || '|' || coalesce(current_setting('request.jwt.claim.sub', true), '');
+  v_cache text := current_setting('app.ctx_unit_scoping', true);
+  v_owner text := current_setting('app.ctx_unit_scoping_key', true);
+  v_out   boolean;
+BEGIN
+  IF v_cache IS NOT NULL AND v_cache <> '' AND v_owner IS NOT DISTINCT FROM v_key THEN
+    RETURN v_cache = 't';
+  END IF;
+  v_out := app._unit_scoping_on_raw();
+  PERFORM set_config('app.ctx_unit_scoping', CASE WHEN v_out THEN 't' ELSE 'f' END, true);
+  PERFORM set_config('app.ctx_unit_scoping_key', v_key, true);
+  RETURN v_out;
+END $function$;
+
+COMMENT ON FUNCTION app.current_tenant_id() IS
+  'O tenant da requisição, calculado UMA vez por transação POR CLAIM. A regra '
+  'mora em app._current_tenant_id_raw() e não mudou. O cache da 076 era local '
+  'à transação sem dizer de quem era a resposta: trocar de sujeito dentro da '
+  'mesma transação devolvia o tenant do sujeito anterior.';
+
+-- ─────────────────────────────────────────────────────────────────────────────
+-- Os outros dois mapas da mesma onda
+-- ─────────────────────────────────────────────────────────────────────────────
+--
+-- A 077 (`app.ctx_perm`) e a 078 (`app.ctx_acl`) guardam MAPAS, e não um valor
+-- só — mas o defeito é idêntico: a chave descreve a pergunta e não quem a fez.
+--
+--     v_chave text := p_perm || '|' || coalesce(p_unit::text, '-');
+--
+-- Duas personas na mesma transação perguntam "people.read" e a segunda recebe
+-- a resposta da primeira. Aqui isso aparecia ao contrário do caso do tenant, e
+-- por isso é mais perigoso: a recepcionista da clínica perdia uma permissão
+-- que tem, e o teste do proprietário ganhava uma que não é dele.
+--
+-- O conserto é o mesmo: a chave passa a dizer de quem é a resposta. Entradas
+-- de outra persona simplesmente não casam. O mapa é local à transação, então
+-- carregar algumas chaves a mais não tem custo que se meça.
+
+CREATE OR REPLACE FUNCTION app.ctx_owner_key()
+ RETURNS text
+ LANGUAGE sql
+ STABLE
+ SET search_path TO ''
+AS $function$
+  SELECT coalesce(current_setting('request.jwt.claims', true), '')
+         || '|' || coalesce(current_setting('request.jwt.claim.sub', true), '')
+$function$;
+
+COMMENT ON FUNCTION app.ctx_owner_key() IS
+  'De quem é a resposta guardada nos caches de contexto (076/077/078). A claim '
+  'inteira, porque auth.uid() e auth.jwt() saem dela — então ela cobre todas as '
+  'entradas das regras cruas.';
+
+CREATE OR REPLACE FUNCTION app.has_permission(p_perm text, p_unit uuid DEFAULT NULL::uuid)
+ RETURNS boolean
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_chave text := app.ctx_owner_key() || '|' || p_perm || '|' || coalesce(p_unit::text, '-');
+  v_mapa  jsonb := coalesce(nullif(current_setting('app.ctx_perm', true), '')::jsonb, '{}'::jsonb);
+  v_out   boolean;
+BEGIN
+  IF v_mapa ? v_chave THEN
+    RETURN (v_mapa ->> v_chave)::boolean;
+  END IF;
+  v_out := app._has_permission_raw(p_perm, p_unit);
+  PERFORM set_config('app.ctx_perm',
+                     (v_mapa || jsonb_build_object(v_chave, v_out))::text, true);
+  RETURN v_out;
+EXCEPTION
+  -- Um cache corrompido não pode virar negação de acesso: se o mapa não
+  -- parsear por qualquer motivo, responde a pergunta do jeito caro.
+  WHEN OTHERS THEN RETURN app._has_permission_raw(p_perm, p_unit);
+END $function$;
+
+CREATE OR REPLACE FUNCTION app.has_unit(p_unit uuid)
+ RETURNS boolean
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_chave text := app.ctx_owner_key() || '|u|' || coalesce(p_unit::text, '-');
+  v_mapa  jsonb := coalesce(nullif(current_setting('app.ctx_acl', true), '')::jsonb, '{}'::jsonb);
+  v_out   boolean;
+BEGIN
+  IF v_mapa ? v_chave THEN RETURN (v_mapa ->> v_chave)::boolean; END IF;
+  v_out := app._has_unit_raw(p_unit);
+  PERFORM set_config('app.ctx_acl', (v_mapa || jsonb_build_object(v_chave, v_out))::text, true);
+  RETURN v_out;
+EXCEPTION WHEN OTHERS THEN RETURN app._has_unit_raw(p_unit);
+END $function$;
+
+CREATE OR REPLACE FUNCTION app.owner_scoped(p_resource_type text)
+ RETURNS boolean
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_chave text := app.ctx_owner_key() || '|o|' || coalesce(p_resource_type, '-');
+  v_mapa  jsonb := coalesce(nullif(current_setting('app.ctx_acl', true), '')::jsonb, '{}'::jsonb);
+  v_out   boolean;
+BEGIN
+  IF v_mapa ? v_chave THEN RETURN (v_mapa ->> v_chave)::boolean; END IF;
+  v_out := app._owner_scoped_raw(p_resource_type);
+  PERFORM set_config('app.ctx_acl', (v_mapa || jsonb_build_object(v_chave, v_out))::text, true);
+  RETURN v_out;
+EXCEPTION WHEN OTHERS THEN RETURN app._owner_scoped_raw(p_resource_type);
+END $function$;
+
+-- ─────────────────────────────────────────────────────────────────────────────
+-- E as funções novas não nascem abertas
+-- ─────────────────────────────────────────────────────────────────────────────
+--
+-- Toda função criada no Postgres nasce com EXECUTE para PUBLIC. A onda de
+-- memoização (076, 077, 078) criou SEIS auxiliares `_raw` em `app` e não
+-- revogou nenhuma; esta migration criou a sétima. O contrato N15c do
+-- `900_verification` mede exatamente isso e contava oito:
+--
+--     anon can execute nothing callable in schema app     have: 8  want: 0
+--
+-- Não é um detalhe de teste. `app._has_permission_raw('people.read')` é a
+-- resposta CRUA da pergunta de permissão, sem cache e sem cerca; deixá-la
+-- aberta a `anon` é deixar a pergunta de autorização atender quem não se
+-- identificou.
+--
+-- As públicas (`current_tenant_id`, `has_permission`, `has_unit`,
+-- `owner_scoped`, `unit_scoping_on`) NÃO são tocadas: elas já existiam, o
+-- `CREATE OR REPLACE` preserva as concessões delas, e as políticas de RLS
+-- dependem de `authenticated` poder chamá-las.
+--
+-- As `_raw` e a chave do cache só são chamadas de dentro de funções
+-- SECURITY DEFINER, que rodam como o dono — então ninguém perde nada.
+
+REVOKE ALL ON FUNCTION app._current_tenant_id_raw()        FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app._current_unit_id_raw()          FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app._unit_scoping_on_raw()          FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app._has_permission_raw(text, uuid) FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app._has_unit_raw(uuid)             FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app._owner_scoped_raw(text)         FROM PUBLIC, anon, authenticated;
+REVOKE ALL ON FUNCTION app.ctx_owner_key()                 FROM PUBLIC, anon, authenticated;
+
+-- As duas que faltavam: `requested_unit` mudou de schema na 076 e `brand_of`
+-- nasceu na 089 — as duas em `app`, as duas abertas a PUBLIC por nascimento.
+REVOKE ALL ON FUNCTION app.requested_unit() FROM PUBLIC, anon;
+REVOKE ALL ON FUNCTION app.brand_of(uuid)   FROM PUBLIC, anon;
+
+-- ─────────────────────────────────────────────────────────────────────────────
+-- E quem MUDA a configuração limpa o cache de quem a lê
+-- ─────────────────────────────────────────────────────────────────────────────
+--
+-- Dizer de quem é a resposta resolve a troca de PESSOA. Falta a outra metade:
+-- a mesma pessoa, na mesma transação, depois que a configuração mudou.
+--
+--     -- ela não alcança B2
+--     INSERT INTO app.membership_units (...) VALUES (... 'caixa-b2' ...);
+--     -- ...e uma linha de configuração depois, alcança
+--
+-- Esse é o contrato que três suítes medem, e é também o que qualquer RPC que
+-- concede acesso e responde em seguida depende. O cache das 076/077/078 é
+-- local à transação: a escrita acontece, e a leitura seguinte devolve a
+-- resposta de antes da escrita. Fica pior que sem cache, porque a função
+-- passa a contradizer uma linha que a própria transação acabou de gravar.
+--
+-- A invalidação não pode ser por tempo nem por versão lida a cada chamada —
+-- as duas custariam o que a memoização economizou. Ela é por EVENTO: quem
+-- escreve na configuração apaga o cache, na mesma transação, de graça.
+--
+-- Gatilho de comando (e não de linha): uma importação de mil vínculos limpa o
+-- cache uma vez, não mil.
+
+CREATE OR REPLACE FUNCTION app.ctx_cache_reset()
+ RETURNS trigger
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+BEGIN
+  PERFORM set_config('app.ctx_tenant',              '', true);
+  PERFORM set_config('app.ctx_tenant_key',          '', true);
+  PERFORM set_config('app.ctx_unit',                '', true);
+  PERFORM set_config('app.ctx_unit_key',            '', true);
+  PERFORM set_config('app.ctx_unit_scoping',        '', true);
+  PERFORM set_config('app.ctx_unit_scoping_key',    '', true);
+  PERFORM set_config('app.ctx_perm',                '', true);
+  PERFORM set_config('app.ctx_acl',                 '', true);
+  RETURN NULL;
+END $function$;
+
+COMMENT ON FUNCTION app.ctx_cache_reset() IS
+  'Apaga os caches de contexto da transação. Ligado a quem ESCREVE a '
+  'configuração que eles resumem: sem isto, uma leitura logo depois de uma '
+  'escrita na mesma transação responde pelo estado anterior.';
+
+REVOKE ALL ON FUNCTION app.ctx_cache_reset() FROM PUBLIC, anon, authenticated;
+
+DO $$
+DECLARE
+  t text;
+  alvo text[] := ARRAY[
+    'app.memberships',        -- de que conta eu sou
+    'app.membership_units',   -- e com que papel em cada unidade
+    'app.roles',
+    'app.role_permissions',   -- o que o papel pode
+    'app.user_unit_access',   -- que unidades eu alcanço
+    'app.resource_grants',    -- e o que está liberado em cada uma
+    'app.units',
+    'app.vertical_owner_scoping',  -- a cerca por ramo tambem e configuracao
+    'public.tenants'          -- inclusive o interruptor unit_scoping_enabled
+  ];
+BEGIN
+  FOREACH t IN ARRAY alvo LOOP
+    IF to_regclass(t) IS NULL THEN CONTINUE; END IF;
+    EXECUTE format('DROP TRIGGER IF EXISTS ctx_cache_reset ON %s', t);
+    EXECUTE format(
+      'CREATE TRIGGER ctx_cache_reset AFTER INSERT OR UPDATE OR DELETE ON %s '
+      'FOR EACH STATEMENT EXECUTE FUNCTION app.ctx_cache_reset()', t);
+  END LOOP;
+END $$;

package/migrations/113_o_ramo_volta_a_saber_que_papeis_a_conta_nasce_tendo.sql

@@ -0,0 +1,124 @@
+-- O ramo volta a saber que papéis a conta nasce tendo
+--
+-- A 093 fechou `tenants.vertical_id` em sete nomes. `create_tenant` derivava o
+-- conjunto de papéis procurando um template com o MESMO nome do ramo:
+--
+--     CASE WHEN EXISTS (SELECT 1 FROM app.role_templates rt
+--                        WHERE rt.template = p_vertical_id)
+--          THEN p_vertical_id ELSE 'generic' END
+--
+-- Os templates se chamam `salon`, `clinic`, `restaurant`, `generic` — o
+-- vocabulário de antes. Nenhum se chama `beauty` nem `food`. Desde a 093,
+-- portanto, TODA conta criada nasce com o template `generic`: sem os papéis do
+-- ofício, com o rail certo e a equipe errada. É o mesmo buraco da 107, no
+-- outro lado da criação da conta, e pela mesma causa — fechar um vocabulário
+-- sem visitar quem o lia.
+--
+-- A saída é a mesma também: traduzir num lugar só, e não batizar os templates
+-- de novo. `beauty` cobre salão e clínica (as duas rodam o StudioControl), e é
+-- por isso que ela cai em `salon`: a clínica é a variante, e quem a quer pede
+-- `p_template` explícito — que continua vencendo a derivação, como sempre.
+--
+-- Idempotente.
+
+CREATE OR REPLACE FUNCTION app.role_template_for_vertical(p_vertical text)
+ RETURNS text
+ LANGUAGE sql
+ STABLE
+ SET search_path TO ''
+AS $function$
+  SELECT coalesce(
+    (SELECT rt.template FROM app.role_templates rt
+      WHERE rt.template = CASE p_vertical
+                            WHEN 'food'   THEN 'restaurant'
+                            WHEN 'beauty' THEN 'salon'
+                            ELSE p_vertical
+                          END
+      LIMIT 1),
+    'generic');
+$function$;
+
+COMMENT ON FUNCTION app.role_template_for_vertical(text) IS
+  'Que conjunto de papéis uma conta daquele ramo nasce tendo. Traduz o '
+  'vocabulário fechado de tenants.vertical_id (093) para os nomes dos '
+  'templates, que são anteriores a ele. Ramo sem template próprio cai em '
+  'generic — que é a resposta honesta, não um erro.';
+
+REVOKE ALL ON FUNCTION app.role_template_for_vertical(text) FROM PUBLIC, anon;
+
+-- E `create_tenant` passa a perguntar a ela. Nada mais muda no corpo: a
+-- definição abaixo é a que estava no banco, com a tradução no lugar do CASE.
+
+CREATE OR REPLACE FUNCTION public.create_tenant(p_name text, p_slug text, p_kind text DEFAULT 'business'::text, p_vertical_id text DEFAULT NULL::text, p_template text DEFAULT 'generic'::text, p_settings jsonb DEFAULT '{}'::jsonb, p_hq_name text DEFAULT NULL::text)
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_uid        uuid := auth.uid();
+  v_tenant     uuid;
+  v_unit       uuid;
+  v_membership uuid;
+  v_owner_role uuid;
+  v_template   text;
+  v_slug       text;
+  v_name       text;
+  v_seeded     jsonb;
+BEGIN
+  IF v_uid IS NULL THEN
+    RAISE EXCEPTION 'create_tenant: the actor is derived from the session and there is no session'
+      USING ERRCODE = '42501';
+  END IF;
+  IF p_kind IS NULL OR p_kind NOT IN ('network', 'business') THEN
+    RAISE EXCEPTION 'create_tenant: kind must be network or business (got %)', coalesce(p_kind, '<null>')
+      USING ERRCODE = '22023';
+  END IF;
+  v_name := nullif(btrim(coalesce(p_name, '')), '');
+  IF v_name IS NULL THEN
+    RAISE EXCEPTION 'create_tenant: name is required' USING ERRCODE = '22023';
+  END IF;
+  v_slug := lower(btrim(coalesce(p_slug, '')));
+  IF v_slug !~ '^[a-z0-9]+([._-][a-z0-9]+)*$' OR length(v_slug) > 100 THEN
+    RAISE EXCEPTION 'create_tenant: slug must be lowercase letters and digits separated by single . _ - (got %)', coalesce(nullif(v_slug, ''), '<empty>')
+      USING ERRCODE = '22023';
+  END IF;
+  IF EXISTS (SELECT 1 FROM public.tenants t WHERE t.slug = v_slug) THEN
+    RAISE EXCEPTION 'create_tenant: slug % is already taken', v_slug USING ERRCODE = '23505';
+  END IF;
+
+  -- Template: explicit, else the vertical's own template when one exists, else generic.
+  v_template := coalesce(p_template, app.role_template_for_vertical(p_vertical_id));
+  IF NOT EXISTS (SELECT 1 FROM app.role_templates rt WHERE rt.template = v_template) THEN
+    RAISE EXCEPTION 'create_tenant: unknown role template %', v_template USING ERRCODE = '22023';
+  END IF;
+
+  INSERT INTO public.tenants (name, slug, plan, vertical_id, kind, settings, role_template)
+  VALUES (v_name, v_slug, 'free', p_vertical_id, p_kind, coalesce(p_settings, '{}'::jsonb), v_template)
+  RETURNING id INTO v_tenant;
+
+  v_owner_role := app.seed_role_template(v_tenant, v_template);
+
+  INSERT INTO app.units (tenant_id, kind, name, slug, active)
+  VALUES (v_tenant, 'hq', coalesce(nullif(btrim(coalesce(p_hq_name, '')), ''), v_name), 'hq', true)
+  RETURNING id INTO v_unit;
+
+  -- The owner: role from the template (holds the whole catalog), every unit.
+  INSERT INTO app.memberships (tenant_id, user_id, role_id, all_units, active)
+  VALUES (v_tenant, v_uid, v_owner_role, true, true)
+  RETURNING id INTO v_membership;
+
+  -- Os plugins do ramo. Mesma transação de propósito: um tenant que existe sem
+  -- plugin nenhum abre uma casca vazia, e quem cria acha que perdeu o que
+  -- digitou. Sem vertical (ou vertical desconhecido) devolve enabled 0 e segue
+  -- — nascer sem ramo é legítimo, nascer pela metade não.
+  v_seeded := public.tenant_apply_vertical_defaults(v_tenant, p_vertical_id);
+
+  RETURN jsonb_build_object(
+    'tenant',     (SELECT to_jsonb(t) FROM public.tenants t WHERE t.id = v_tenant),
+    'hq_unit',    (SELECT to_jsonb(u) FROM app.units u WHERE u.id = v_unit),
+    'membership', (SELECT to_jsonb(m) FROM app.memberships m WHERE m.id = v_membership),
+    'plugins',    v_seeded
+  );
+END $function$
+;

package/migrations/114_a_resposta_inicial_volta_a_dizer_o_que_a_pessoa_pode.sql

@@ -0,0 +1,93 @@
+-- A resposta inicial volta a dizer o que a pessoa pode, e quando foi tirada
+--
+-- A 092 reescreveu `app_config()` para devolver o preset do ofício — e, ao
+-- repetir a função inteira, deixou cair duas chaves que a 001 entregava:
+--
+--     permissions    a cerca do cliente: sem ela a tela monta sem saber o que
+--                    esconder, e todo `can()` responde pelo padrão
+--     generated_at   a idade da resposta: sem ela o snapshot em localStorage
+--                    não tem como saber se ainda vale
+--
+-- Nenhuma das duas some com estrondo. A tela abre, a marca pinta, o rail
+-- desenha — e a cerca fica por conta do padrão enquanto o cache nunca vence.
+-- É a forma mais cara de erro: a que parece estar funcionando.
+--
+-- Repetida inteira de novo, que é como uma função volta a ter dono. Só as
+-- duas chaves mudam; o resto é byte a byte o que a 092 deixou.
+--
+-- Nota sobre `plugins`: ela continua devolvendo TODAS as linhas, inclusive as
+-- desligadas e as de teste vencido (com `status` já resolvido para
+-- 'disabled'). Isso não é descuido — é o contrato novo. A resolução no cliente
+-- é ADITIVA: linha ausente cai no padrão do manifesto, que é LIGADO. Uma conta
+-- só consegue dizer "isto eu não uso" se a linha que diz isso chegar.
+--
+-- Numerada DEPOIS da 113, de propósito: aquela vem do outro ramo e reemite
+-- `app_config()` na linhagem de lá — sem a guarda do schema `platform` e sem
+-- as duas chaves. Quem define por último é quem define; renumerar custa nada e
+-- deixa o arquivo do outro ramo byte a byte como ele é lá.
+--
+-- Idempotente.
+
+CREATE OR REPLACE FUNCTION public.app_config()
+RETURNS jsonb
+LANGUAGE plpgsql
+STABLE SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  v_staff  text;
+BEGIN
+  -- `platform` e o schema do control-admin: existe no cluster que hospeda a
+  -- plataforma e NAO na cadeia canonica, onde esta funcao e reconstruida do
+  -- zero. Chamar direto compila (o corpo de plpgsql so resolve nomes na
+  -- primeira execucao) e estoura na primeira chamada com "schema platform
+  -- does not exist" — que e o pedagio de `search_path` vazio ja pago na
+  -- 060. Perguntar antes deixa a mesma definicao servir aos dois: sem o
+  -- schema, ninguem e staff, e o control-admin simplesmente nao e oferecido.
+  IF pg_catalog.to_regproc('platform.staff_role(uuid)') IS NOT NULL THEN
+    EXECUTE 'SELECT platform.staff_role($1)' INTO v_staff USING (SELECT auth.uid());
+  END IF;
+
+  IF v_tenant IS NULL THEN
+    RETURN jsonb_build_object('tenant_id', NULL, 'plugins', '[]'::jsonb, 'nav', '[]'::jsonb,
+                              'apps', '[]'::jsonb, 'permissions', '[]'::jsonb, 'generated_at', now());
+  END IF;
+
+  RETURN jsonb_build_object(
+    'tenant_id', v_tenant,
+    'branding',  coalesce(app.brand_of(v_tenant), '{}'::jsonb),
+    'settings',  public.tenant_settings(),
+    -- Todas as linhas, inclusive as desligadas: a regra no cliente é aditiva, e
+    -- uma linha ausente cai no padrão do manifesto — que é LIGADO.
+    'plugins', coalesce((
+      SELECT jsonb_agg(jsonb_build_object('plugin', t.plugin_id, 'facet', nullif(t.facet, ''),
+               'status', CASE WHEN t.expires_at IS NOT NULL AND t.expires_at <= now() THEN 'disabled' ELSE t.status END,
+               'source', t.source, 'config', t.config, 'expires_at', t.expires_at)
+             ORDER BY t.plugin_id, t.facet)
+        FROM app.tenant_plugins t WHERE t.tenant_id = v_tenant), '[]'::jsonb),
+    'apps', coalesce((
+      SELECT jsonb_agg(x ORDER BY x ->> 'house', x ->> 'name') FROM (
+        SELECT jsonb_build_object('id', a.id, 'name', a.name, 'icon', a.icon, 'accent_color', a.accent_color,
+                 'url', a.url, 'house', false, 'preset', a.preset) AS x
+          FROM app.tenant_apps ta JOIN app.apps a ON a.id = ta.app_id
+         WHERE ta.tenant_id = v_tenant AND ta.status = 'active' AND a.active
+        UNION ALL
+        SELECT jsonb_build_object('id', a.id, 'name', a.name, 'icon', a.icon, 'accent_color', a.accent_color,
+                 'url', a.url, 'house', true, 'preset', a.preset) AS x
+          FROM app.apps a WHERE v_staff IS NOT NULL AND a.id = 'control-admin' AND a.active AND a.url IS NOT NULL) apps), '[]'::jsonb),
+    'nav', coalesce((
+      SELECT jsonb_agg(jsonb_build_object('key', n.entry_key, 'hidden', n.hidden, 'label', n.label,
+               'section', n.section, 'position', n.position) ORDER BY n.entry_key)
+        FROM app.tenant_nav n WHERE n.tenant_id = v_tenant), '[]'::jsonb),
+    -- As duas que a reescrita da 092 deixou cair, de volta com a mesma forma
+    -- da 001: o cliente monta a cerca com `permissions` e decide a validade do
+    -- snapshot com `generated_at`.
+    'permissions', coalesce((
+      SELECT jsonb_agg(DISTINCT rp.permission)
+        FROM app.memberships m
+        JOIN app.role_permissions rp ON rp.role_id = m.role_id AND rp.tenant_id = m.tenant_id
+       WHERE m.tenant_id = v_tenant AND m.user_id = (SELECT auth.uid()) AND m.active
+    ), '[]'::jsonb),
+    'generated_at', now());
+END $function$;

package/migrations/115_o_rail_e_de_quem_tem_um.sql

@@ -0,0 +1,108 @@
+-- ---------------------------------------------------------------------------
+-- 115_o_rail_e_de_quem_tem_um.sql
+-- ---------------------------------------------------------------------------
+-- O ControlGroup roda dois aplicativos — o FullControl, que é o sistema dele, e
+-- o FiscalControl, que é a retaguarda contábil. O rail que ele desenhava era o
+-- de NINGUÉM: linhas soltas, sem as rubricas que o FullControl declara.
+--
+-- ── Por que ─────────────────────────────────────────────────────────────────
+-- `useAppPreset` usa o preset do PRIMEIRO aplicativo da lista, e com razão: um
+-- rail com as duas árvores não é a soma de dois sistemas, é nenhum dos dois.
+-- Quem ordena a lista é esta função, e ela ordenava assim:
+--
+--     ORDER BY house, trade DESC, name
+--
+-- `trade` é "tem ofício" (vertical fora de `accounting`/`generic`). Nem o
+-- `full` nem o `fiscal` têm: um é o ERP genérico e o outro é contabilidade. Com
+-- os dois empatados em `trade`, o desempate caía no NOME — e "FiscalControl"
+-- vem antes de "FullControl" no alfabeto.
+--
+-- Então o aplicativo sem opinião nenhuma sobre o rail (o `fiscal` não declara
+-- `preset.rail`) vencia o que declara a árvore inteira, por uma letra.
+--
+-- ── O conserto ──────────────────────────────────────────────────────────────
+-- Um critério a mais, ANTES do nome: quem TEM rail ganha de quem não tem.
+--
+-- Não é um caso particular do ControlGroup. Um aplicativo sem `preset.rail` é
+-- um que não opina sobre a navegação — a retaguarda, o complemento —, e ele
+-- nunca deveria calar o que opina. O alfabeto não sabe disso; esta linha sabe.
+--
+-- `trade` continua vindo primeiro: entre dois que declaram rail, quem tem
+-- ofício manda, que é o que a 084 resolveu para o Artorius.
+--
+-- Idempotente: reemite a função.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION public.app_config()
+ RETURNS jsonb
+ LANGUAGE plpgsql
+ STABLE SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+DECLARE
+  v_tenant uuid := app.current_tenant_id();
+  v_staff  text;
+BEGIN
+  -- `platform` é do CLUSTER, não da cadeia canônica: um banco montado do zero
+  -- (o db-from-zero, um pool novo) não tem esse schema, e uma chamada direta
+  -- estoura na inicialização da variável — antes de qualquer linha do corpo.
+  -- Mesma guarda que a 092 já precisou pôr aqui; reemitir a função copiando a
+  -- definição VIVA do cluster a trouxe de volta.
+  IF pg_catalog.to_regproc('platform.staff_role(uuid)') IS NOT NULL THEN
+    EXECUTE 'SELECT platform.staff_role($1)' INTO v_staff USING (SELECT auth.uid());
+  END IF;
+
+  IF v_tenant IS NULL THEN
+    RETURN jsonb_build_object('tenant_id', NULL, 'plugins', '[]'::jsonb, 'nav', '[]'::jsonb,
+                              'apps', '[]'::jsonb, 'permissions', '[]'::jsonb, 'generated_at', now());
+  END IF;
+
+  RETURN jsonb_build_object(
+    'tenant_id', v_tenant,
+    'branding',  coalesce(app.brand_of(v_tenant), '{}'::jsonb),
+    'settings',  public.tenant_settings(),
+    'plugins', coalesce((
+      SELECT jsonb_agg(jsonb_build_object('plugin', t.plugin_id, 'facet', nullif(t.facet, ''),
+               'status', CASE WHEN t.expires_at IS NOT NULL AND t.expires_at <= now() THEN 'disabled' ELSE t.status END,
+               'source', t.source, 'config', t.config, 'expires_at', t.expires_at)
+             ORDER BY t.plugin_id, t.facet)
+        FROM app.tenant_plugins t WHERE t.tenant_id = v_tenant), '[]'::jsonb),
+    -- `trade` ordena a lista: quem roda dois aplicativos tem UM ofício, e o
+    -- outro é retaguarda. FiscalControl vinha antes de StoreControl só por
+    -- ordem alfabética, e o Artorius desenhava o rail de ninguém.
+    --
+    -- E entre dois SEM ofício — o ERP genérico e a contabilidade —, quem
+    -- declara `preset.rail` vence quem não declara: um aplicativo que não opina
+    -- sobre a navegação não pode calar o que opina só por vir antes no
+    -- alfabeto (115).
+    'apps', coalesce((
+      SELECT jsonb_agg(x ORDER BY x ->> 'house',
+                                  (x ->> 'trade')::boolean DESC,
+                                  (x -> 'preset' -> 'rail' IS NOT NULL) DESC,
+                                  x ->> 'name') FROM (
+        SELECT jsonb_build_object('id', a.id, 'name', a.name, 'icon', a.icon, 'accent_color', a.accent_color,
+                 'url', a.url, 'house', false, 'preset', a.preset, 'vertical_id', a.vertical_id,
+                 'trade', a.vertical_id IS NOT NULL AND a.vertical_id NOT IN ('accounting','generic')) AS x
+          FROM app.tenant_apps ta JOIN app.apps a ON a.id = ta.app_id
+         WHERE ta.tenant_id = v_tenant AND ta.status = 'active' AND a.active
+        UNION ALL
+        SELECT jsonb_build_object('id', a.id, 'name', a.name, 'icon', a.icon, 'accent_color', a.accent_color,
+                 'url', a.url, 'house', true, 'preset', a.preset, 'vertical_id', a.vertical_id,
+                 'trade', false) AS x
+          FROM app.apps a WHERE v_staff IS NOT NULL AND a.id = 'control-admin' AND a.active AND a.url IS NOT NULL) apps), '[]'::jsonb),
+    'nav', coalesce((
+      SELECT jsonb_agg(jsonb_build_object('key', n.entry_key, 'hidden', n.hidden, 'label', n.label,
+               'section', n.section, 'position', n.position) ORDER BY n.entry_key)
+        FROM app.tenant_nav n WHERE n.tenant_id = v_tenant), '[]'::jsonb),
+    -- As duas que a 114 devolveu, e que esta migration quase derrubou de novo:
+    -- copiei a definição VIVA do cluster, onde a 114 ainda não rodou. É a
+    -- terceira vez que repetir esta função inteira perde uma chave dela — quem
+    -- a reemite tem de começar pelo ARQUIVO da última, não pelo banco.
+    'permissions', coalesce((
+      SELECT jsonb_agg(DISTINCT rp.permission)
+        FROM app.memberships m
+        JOIN app.role_permissions rp ON rp.role_id = m.role_id AND rp.tenant_id = m.tenant_id
+       WHERE m.tenant_id = v_tenant AND m.user_id = (SELECT auth.uid()) AND m.active
+    ), '[]'::jsonb),
+    'generated_at', now());
+END $function$;

package/package.json

@@ -3,7 +3,7 @@
   "fayz": {
     "status": "beta"
   },
-  "version": "0.14.0",
+  "version": "0.16.0",
   "description": "Fayz SDK database layer — Drizzle schema primitives, spine references, and migration helpers shared across plugins.",
   "type": "module",
   "sideEffects": false,