@fayz-ai/db 0.18.2 → 0.20.1

package/migrations/147_tres_saloes_desligam_o_rh.sql

@@ -0,0 +1,30 @@
+-- ============================================================================
+-- 147 — três salões desligam o RH
+--
+-- Espaço Facial, Walter's Coiffeur e Além do Olhar não têm departamento de
+-- pessoal: quem trabalha lá é profissional que atende, e o cadastro disso já
+-- mora em Cadastros → Funcionários. A linha "RH" no rail abria um módulo
+-- inteiro (ponto, escalas, folha) que nenhuma das três usa — e um item de menu
+-- que ninguém abre ainda custa: ele empurra para baixo os que abrem todo dia.
+--
+-- Por conta e não por preset: as três dividem o StudioControl com salões que
+-- talvez queiram RH. `app.tenant_plugins` é onde isso se decide — um plugin
+-- desligado não contribui rota, menu, aba de configuração nem widget
+-- (`resolvePluginRuntime`), então a tela deixa de existir para elas em vez de
+-- ficar escondida e alcançável por link.
+--
+-- `source = 'manual'` porque foi decisão da casa, não do plano nem do padrão do
+-- ofício — e é o que impede um `tenant_apply_vertical_defaults` de reativá-lo
+-- sem querer.
+-- ============================================================================
+
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT t.id, 'workforce', '', 'disabled', 'manual'
+  FROM public.tenants t
+ WHERE t.id IN (
+   'af800ef8-853d-543f-9940-1e9a5663c061',  -- Espaço Facial
+   'c3a8f61d-742b-4e05-9d16-8b47e2f0a5c3',  -- Walter's Coiffeur
+   'b1d7c4e2-9a3f-4c18-8f52-6e0a7d3b4c91'   -- Além do Olhar
+ )
+ON CONFLICT (tenant_id, plugin_id, facet)
+DO UPDATE SET status = 'disabled', source = 'manual', updated_at = now();

package/migrations/148_servicos_ganham_a_permissao_que_nunca_tiveram.sql

@@ -0,0 +1,37 @@
+-- ============================================================================
+-- 148 — Serviços ganham a permissão que nunca tiveram
+--
+-- O `plugin-registry` tranca quatro telas — Serviços, Categorias de Serviço,
+-- Locais Operacionais e Grupos de Locais — atrás de `feature: 'services'`. A
+-- chave `services.*` NUNCA foi cunhada em `app.permissions`: ela não está no
+-- catálogo, então papel nenhum a tem, e nenhuma tela ligada a ela desenha.
+--
+-- Só o OWNER via as quatro, porque owner lê o catálogo em vez da lista
+-- congelada do papel. Daí o sintoma confuso: as mesmas telas apareciam numa
+-- conta e sumiam na outra conforme o papel de quem entrou, sem erro e sem
+-- explicação. São 30 contas com admin ou gerente nesse estado.
+--
+-- A permissão vai onde o `catalog.*` já vai, e por isso: as duas respondem à
+-- mesma pergunta — quem mantém o que a casa OFERECE. Quem pode ler o catálogo
+-- pode ler os serviços; quem edita, edita. Sem inventar audiência nova, e sem
+-- dar a ninguém algo que já não tivesse.
+--
+-- Idempotente.
+-- ============================================================================
+
+INSERT INTO app.permissions (key, plugin, description)
+VALUES
+  ('services.read',   'registry', 'Ver serviços, categorias de serviço, locais operacionais e grupos de locais'),
+  ('services.create', 'registry', 'Cadastrar serviço, categoria, local operacional ou grupo de locais'),
+  ('services.edit',   'registry', 'Alterar serviço, categoria, local operacional ou grupo de locais'),
+  ('services.delete', 'registry', 'Excluir serviço, categoria, local operacional ou grupo de locais'),
+  ('services.manage', 'registry', 'Coringa de serviços — vale por ler, criar, alterar e excluir')
+ON CONFLICT (key) DO NOTHING;
+
+-- Espelha o que cada papel já pode no catálogo. `manage` é coringa e viaja
+-- junto: um papel que administra o catálogo administra o que a casa oferece.
+INSERT INTO app.role_permissions (role_id, permission, tenant_id)
+SELECT p.role_id, replace(p.permission, 'catalog.', 'services.'), p.tenant_id
+  FROM app.role_permissions p
+ WHERE p.permission IN ('catalog.read', 'catalog.create', 'catalog.edit', 'catalog.delete', 'catalog.manage')
+ON CONFLICT DO NOTHING;

package/migrations/149_a_conta_do_fornecedor_nao_e_conta_da_casa.sql

@@ -0,0 +1,131 @@
+-- ---------------------------------------------------------------------------
+-- 149_a_conta_do_fornecedor_nao_e_conta_da_casa.sql
+--
+-- `public.payee_accounts` — para onde vai o dinheiro de QUEM A CASA PAGA.
+--
+-- ── por que uma tabela, e não oito chaves em custom_fields ──────────────
+--
+-- É o mesmo argumento que a 142 fez para endereço, e a 117 para o Instagram:
+-- dado de contato guardado numa sacola jsonb não é buscável, não é exportável,
+-- não é conferível, e nenhuma consulta o alcança. A remessa CNAB 240 precisa
+-- varrer «todos os fornecedores com conta cadastrada» — em `custom_fields`
+-- isso é um scan de jsonb sobre a tabela inteira de pessoas.
+--
+-- E há o motivo de forma: uma pessoa pode ter MAIS DE UMA conta (a do CNPJ e a
+-- do sócio; a corrente e a poupança do INSS). Oito colunas numa linha de pessoa
+-- decidem por ela que só existe uma.
+--
+-- ── e por que uma tabela NOVA, e não `plg_financial_accounts` ───────────
+--
+-- Esta é a pergunta que o cadastro de Contas responde errado se a resposta for
+-- «reaproveita». `plg_financial_accounts` é o RAZÃO da casa: cada linha dela é
+-- dinheiro que o tenant tem, concilia e fecha. A conta do fornecedor não é
+-- dinheiro da casa — é uma INSTRUÇÃO DE PAGAMENTO, um endereço para onde o
+-- dinheiro sai.
+--
+-- Misturar as duas põe a conta do fornecedor na lista de Contas, no seletor de
+-- «Receber em», no extrato e no saldo consolidado. Não existe filtro que
+-- conserte isso com segurança: basta uma tela nova esquecer o recorte e a conta
+-- de terceiro vira caixa da empresa. Tabelas separadas tornam o vazamento
+-- impossível por construção, que é a única garantia que não depende de ninguém
+-- lembrar.
+--
+-- (`plg_financial_bank_accounts` é a tabela LEGADA, encaminhada por gatilho
+-- para `plg_financial_accounts`. Não é candidata a nada.)
+--
+-- ── titular ─────────────────────────────────────────────────────────────
+--
+-- `holder_name` e `holder_document` existem porque a conta raramente está no
+-- nome de quem presta o serviço: está no do MEI, da esposa, da holding. Quem
+-- faz a transferência precisa bater o documento antes de mandar, ou paga o
+-- titular errado com o nome certo.
+-- ---------------------------------------------------------------------------
+
+CREATE TABLE IF NOT EXISTS public.payee_accounts (
+  id uuid DEFAULT gen_random_uuid() NOT NULL,
+  tenant_id uuid NOT NULL,
+
+  -- Polimórfico como `addresses`, e pelas mesmas razões: fornecedor, parceiro,
+  -- profissional e funcionário são todos `people`, e a unidade também recebe.
+  owner_type text DEFAULT 'person'::text NOT NULL,
+  owner_id uuid NOT NULL,
+
+  -- «Conta do MEI», «Poupança». Nulo é aceitável: a maioria tem uma só.
+  label text,
+  is_default boolean DEFAULT false NOT NULL,
+
+  -- O NÚMERO do banco antes do nome: «077» é como o boleto, o CNAB e o PIX
+  -- chamam o Inter; «Inter» é como a pessoa chama. O cadastro precisa dos dois,
+  -- e o porte do V1 mostrou o custo de não separar — lá as duas coisas dividem
+  -- a mesma coluna e há conta guardando o código onde deveria estar o nome.
+  bank_code text,
+  bank_name text,
+
+  -- Dígito em coluna própria: a remessa CNAB 240 lê agência e dígito em campos
+  -- separados, e partir «1344-7» na hora de gerar o arquivo é pagamento
+  -- devolvido quando alguém digitou «1344/7».
+  agency_number text,
+  agency_digit text,
+  account_number text,
+  account_digit text,
+  account_type text,
+
+  -- O tipo da chave PIX não se deduz com segurança do formato: um telefone sem
+  -- o +55 e um CPF são ambos onze dígitos, e mandar um como o outro paga a
+  -- pessoa errada. Quem escolhe é quem cadastra.
+  pix_key text,
+  pix_key_type text,
+
+  holder_name text,
+  holder_document text,
+
+  notes text,
+  created_at timestamp with time zone DEFAULT now() NOT NULL,
+  updated_at timestamp with time zone DEFAULT now() NOT NULL,
+
+  CONSTRAINT payee_accounts_pkey PRIMARY KEY (id),
+  CONSTRAINT payee_accounts_owner_type_check
+    CHECK (owner_type = ANY (ARRAY['person'::text, 'unit'::text, 'tenant'::text])),
+  CONSTRAINT payee_accounts_account_type_check
+    CHECK (account_type IS NULL OR account_type = ANY (ARRAY['corrente'::text, 'poupanca'::text, 'pagamento'::text])),
+  CONSTRAINT payee_accounts_pix_key_type_check
+    CHECK (pix_key_type IS NULL OR pix_key_type = ANY (ARRAY['cpf'::text, 'cnpj'::text, 'email'::text, 'telefone'::text, 'aleatoria'::text])),
+
+  -- Uma linha SEM conta e SEM PIX não é um dado, é um formulário aberto por
+  -- engano. A tela já recusa antes; isto é a rede.
+  CONSTRAINT payee_accounts_has_something
+    CHECK (account_number IS NOT NULL OR pix_key IS NOT NULL)
+);
+
+COMMENT ON TABLE public.payee_accounts IS
+  'Para onde o dinheiro SAI: conta e PIX de quem a casa paga (fornecedor, parceiro, profissional, funcionário). NÃO é conta do razão — o dinheiro da casa vive em plg_financial_accounts, e misturar as duas põe a conta de terceiro no extrato e no saldo da empresa.';
+
+COMMENT ON COLUMN public.payee_accounts.holder_document IS
+  'A conta raramente está no nome de quem presta o serviço. Quem transfere bate o documento antes de mandar.';
+
+-- O caminho que toda tela faz: «as contas desta pessoa».
+CREATE INDEX IF NOT EXISTS payee_accounts_owner_idx
+  ON public.payee_accounts (tenant_id, owner_type, owner_id);
+
+-- Uma principal por dono. Sem isto, duas linhas marcadas como padrão fazem a
+-- tela mostrar uma e a remessa pagar a outra.
+CREATE UNIQUE INDEX IF NOT EXISTS payee_accounts_one_default_uidx
+  ON public.payee_accounts (tenant_id, owner_type, owner_id)
+  WHERE is_default;
+
+ALTER TABLE public.payee_accounts ENABLE ROW LEVEL SECURITY;
+ALTER TABLE public.payee_accounts FORCE ROW LEVEL SECURITY;
+
+-- Mesmo recorte de `addresses`: quem é da conta vê o que é da conta. Sem a
+-- política de leitura pública que `addresses` tem para o comprador da loja —
+-- dado bancário de terceiro não tem leitor anônimo.
+DROP POLICY IF EXISTS payee_accounts_member_all ON public.payee_accounts;
+CREATE POLICY payee_accounts_member_all ON public.payee_accounts
+  TO authenticated
+  USING (tenant_id IN (SELECT public.user_tenant_ids()))
+  WITH CHECK (tenant_id IN (SELECT public.user_tenant_ids()));
+
+DROP TRIGGER IF EXISTS payee_accounts_set_updated_at ON public.payee_accounts;
+CREATE TRIGGER payee_accounts_set_updated_at
+  BEFORE UPDATE ON public.payee_accounts
+  FOR EACH ROW EXECUTE FUNCTION public.handle_updated_at();

package/migrations/150_todo_cadastro_tem_observacao_e_etiqueta.sql

@@ -0,0 +1,62 @@
+-- ---------------------------------------------------------------------------
+-- 150_todo_cadastro_tem_observacao_e_etiqueta.sql
+--
+-- `notes` e `tags` nas tabelas de cadastro do núcleo.
+--
+-- ── por que TODO cadastro, e não «quem pedir» ──────────────────────────
+--
+-- O rail direito de uma ficha responde sempre às mesmas quatro perguntas: de
+-- que unidade é, se vale, o que alguém anotou, e como a casa recorta este
+-- registro. Hoje só `people` consegue responder às duas últimas — e o
+-- resultado é que a mesma tela muda de forma conforme o cadastro: o operador
+-- que aprendeu a etiquetar um cliente não acha a etiqueta no serviço, e
+-- conclui que não existe.
+--
+-- Um lugar fixo só é fixo se estiver em todos.
+--
+-- ── etiqueta é recorte, não classificação ──────────────────────────────
+--
+-- `categories` já existe para classificar, e não é substituta: a categoria diz
+-- O QUE a coisa é (uma taxonomia que alguém manteve), a etiqueta diz como ESTA
+-- casa a recorta, hoje, para um fim que o produto não previu — «sem estoque no
+-- fornecedor», «promoção de julho», «serviço que a Ana faz». Sem ela isso vai
+-- para as observações, onde não filtra e não conta.
+--
+-- `text[]` e não uma tabela de junção: etiqueta é escrita e lida junto com a
+-- linha, sempre, e um índice GIN responde «quem tem esta» sem uma segunda
+-- tabela para manter. É a mesma escolha que `people.tags` já tinha feito.
+-- ---------------------------------------------------------------------------
+
+ALTER TABLE public.categories
+  ADD COLUMN IF NOT EXISTS notes text,
+  ADD COLUMN IF NOT EXISTS tags text[] DEFAULT '{}'::text[];
+
+ALTER TABLE public.products
+  ADD COLUMN IF NOT EXISTS notes text;
+
+-- `public.services` SÓ SE ELA EXISTIR.
+--
+-- O espelho foi aposentado pela 191 do spine — um serviço é um produto de
+-- `kind='service'`. Num pool antigo a tabela continua lá e precisa da coluna;
+-- num banco levantado do zero ela não nasce, e um `ALTER TABLE` direto derruba
+-- a cadeia inteira em `relation "public.services" does not exist`. Foi o que o
+-- db-from-zero pegou.
+DO $servicos$
+BEGIN
+  IF to_regclass('public.services') IS NOT NULL THEN
+    EXECUTE 'ALTER TABLE public.services ADD COLUMN IF NOT EXISTS notes text';
+    EXECUTE 'CREATE INDEX IF NOT EXISTS services_tags_gin ON public.services USING gin (tags)';
+  END IF;
+END $servicos$;
+
+-- `products.tags` e `services.tags` já existem — quem chegou primeiro estava
+-- certo, e isto só empata o resto.
+
+COMMENT ON COLUMN public.categories.tags IS
+  'Como ESTA casa recorta o registro, para um fim que o produto não previu. Diferente de uma categoria, que diz o que a coisa É.';
+
+-- «Quem tem esta etiqueta» sem varrer a tabela. A coluna nasce para filtrar;
+-- sem índice ela seria um campo bonito que trava a lista no primeiro uso.
+CREATE INDEX IF NOT EXISTS categories_tags_gin ON public.categories USING gin (tags);
+CREATE INDEX IF NOT EXISTS products_tags_gin ON public.products USING gin (tags);
+CREATE INDEX IF NOT EXISTS people_tags_gin ON public.people USING gin (tags);

package/migrations/151_a_parceria_e_uma_especie_de_pessoa.sql

@@ -0,0 +1,35 @@
+-- ---------------------------------------------------------------------------
+-- 151_a_parceria_e_uma_especie_de_pessoa.sql
+--
+-- `partner` entra no censo de espécies de pessoa.
+--
+-- ── o sintoma ──────────────────────────────────────────────────────────
+--
+-- Salvar uma parceria devolvia:
+--
+--   insert or update on table "people" violates foreign key constraint
+--   "people_kind_registered"
+--
+-- O cadastro de Parcerias sempre gravou `people.kind = 'partner'` — está no
+-- `archetypeKind` da entidade desde que ela existe —, e `person_kinds` nunca
+-- teve a linha. Ou seja: o cadastro NUNCA conseguiu criar um registro. Não é
+-- regressão; é uma tela que nasceu sem porta e ninguém tinha tentado abrir.
+--
+-- ── e por que o censo não pegou ────────────────────────────────────────
+--
+-- `check-kind-registry.mjs` existe exatamente para isto, e passava limpo: ele
+-- varre os arquivos SQL de cada plugin procurando `INSERT INTO people (kind)
+-- VALUES ('…')`. Só que NENHUM cadastro do produto escreve assim — quem grava
+-- é o CRUD genérico, a partir do `archetypeKind` declarado em TypeScript. O
+-- verificador cobria o caminho que quase ninguém usa e deixava de fora o
+-- principal. O script foi estendido junto com esta migration.
+--
+-- `plugin-registry` não tem migrations próprias, e por isso a declaração mora
+-- aqui, ao lado das outras espécies de pessoa do núcleo (contact, supplier,
+-- staff), que também são dele.
+-- ---------------------------------------------------------------------------
+
+SELECT public.register_kind(
+  'person', 'partner', 'base', NULL, NULL,
+  'Quem indica cliente ou divide receita com a casa — a academia ao lado, o hotel, o dentista que encaminha. Pessoa como as outras: tem contato, endereço e conta para receber.'
+);

package/migrations/152_a_profissao_e_a_especie_de_pet_sao_catalogos.sql

@@ -0,0 +1,31 @@
+-- ---------------------------------------------------------------------------
+-- 152 — Profissão e espécie de pet entram no censo de categorias.
+--
+-- Dois cadastros que o V1 tem e o V2 não tinha:
+--
+--   `profession`  — `professions` do V1. O que o profissional FAZ, escolhido de
+--                   uma lista que a casa mantém. Hoje o V2 pergunta em texto
+--                   livre, e «Esteticista», «esteticista» e «Esteticista(a)»
+--                   viram três profissões na hora de montar uma escala ou
+--                   filtrar quem pode executar um serviço.
+--
+--   `pet_species` — `pet_species` do V1. Cachorro, gato, ave. Só aparece em
+--                   casa que atende pet, e é por isso que é catálogo por conta
+--                   e não lista fixa: um hotel para aves não quer «cachorro»
+--                   na primeira posição.
+--
+-- As duas são CATEGORIAS: nome, ordem, ativo. Não merecem tabela própria —
+-- `categories` existe exatamente para as taxonomias que cada casa mantém, e
+-- foi por não usá-la que o V1 acabou com uma tabela de cinco colunas por
+-- vocabulário.
+-- ---------------------------------------------------------------------------
+
+SELECT public.register_kind(
+  'category', 'profession', 'base', NULL, NULL,
+  'O que o profissional faz — a lista que a casa mantém, para a escala e o filtro de quem executa cada serviço não dependerem de como alguém digitou.'
+);
+
+SELECT public.register_kind(
+  'category', 'pet_species', 'base', NULL, NULL,
+  'Espécie de animal atendido (cachorro, gato, ave). Catálogo por conta: um hotel para aves não quer cachorro na primeira posição.'
+);

package/migrations/153_a_sala_nao_e_a_filial.sql

@@ -0,0 +1,94 @@
+-- ---------------------------------------------------------------------------
+-- 153_a_sala_nao_e_a_filial.sql
+--
+-- `public.rooms` — a SALA onde se atende, dentro de uma unidade.
+--
+-- ── o conflito que esta migration resolve ──────────────────────────────
+--
+-- O V2 chamava de «Local de Atendimento» a FILIAL (`v_units`). No V1, Local
+-- Operacional é outra coisa: a sala, a cadeira, o box — tem `unit_id`, um
+-- grupo e uma LOTAÇÃO (`max_simultaneous_clients`), e é o que o cadastro de
+-- Equipamentos referencia («este aparelho está na Sala 2»).
+--
+-- Dois cadastros com o mesmo nome e granularidades diferentes: quem procurava
+-- a sala achava a filial, e a agenda não tinha como dizer que duas clientes
+-- não cabem na mesma cadeira ao mesmo tempo.
+--
+-- ── por que tabela, e não uma unidade «filha» ──────────────────────────
+--
+-- `v_units` já tem hierarquia (região → unidade), e a tentação é pendurar a
+-- sala como um terceiro nível. Não serve: uma unidade é onde a RLS corta, onde
+-- o caixa fecha e onde o estoque mora. Uma sala não corta nada disso — ela não
+-- tem caixa, não tem estoque e não recorta permissão. Torná-la unidade faria
+-- cada sala multiplicar o escopo de tudo que hoje é por unidade.
+--
+-- ── lotação ────────────────────────────────────────────────────────────
+--
+-- `capacity` é o que o V1 chama de «máximo de clientes simultâneos»: uma sala
+-- de banho tem uma cadeira, uma sala de bronzeamento tem quatro. É o número
+-- que impede a agenda de marcar cinco pessoas às 14h onde cabem quatro — e
+-- sem ele a sala é só um rótulo.
+-- ---------------------------------------------------------------------------
+
+CREATE TABLE IF NOT EXISTS public.rooms (
+  id uuid DEFAULT gen_random_uuid() NOT NULL,
+  tenant_id uuid NOT NULL,
+
+  -- A unidade em que a sala fica. NOT NULL: uma sala sem prédio não existe, e
+  -- é por `unit_id` que a agenda e o equipamento a alcançam.
+  unit_id uuid NOT NULL,
+
+  name text NOT NULL,
+  code text,
+
+  -- O grupo é como a casa junta salas parecidas («Estética», «Banho e tosa»)
+  -- para escalar e para relatório. `categories` com kind `location_group` já
+  -- existe e serve — não vale uma tabela para uma palavra.
+  group_id uuid,
+
+  -- Quantas pessoas cabem ao mesmo tempo. 1 é o caso comum (uma cadeira).
+  capacity integer DEFAULT 1 NOT NULL,
+
+  notes text,
+  tags text[] DEFAULT '{}'::text[],
+  is_active boolean DEFAULT true NOT NULL,
+  custom_fields jsonb DEFAULT '{}'::jsonb NOT NULL,
+  created_at timestamp with time zone DEFAULT now() NOT NULL,
+  updated_at timestamp with time zone DEFAULT now() NOT NULL,
+  created_by uuid,
+
+  CONSTRAINT rooms_pkey PRIMARY KEY (id),
+  CONSTRAINT rooms_capacity_positive CHECK (capacity >= 1),
+  CONSTRAINT rooms_group_fk FOREIGN KEY (group_id) REFERENCES public.categories(id) ON DELETE SET NULL
+);
+
+COMMENT ON TABLE public.rooms IS
+  'A sala, cadeira ou box onde se atende, DENTRO de uma unidade. Não é unidade: não tem caixa, não tem estoque e não recorta permissão — o que ela tem é lotação.';
+
+COMMENT ON COLUMN public.rooms.capacity IS
+  'Quantas pessoas cabem ao mesmo tempo. É o que impede a agenda de marcar cinco às 14h onde cabem quatro.';
+
+CREATE INDEX IF NOT EXISTS rooms_unit_idx ON public.rooms (tenant_id, unit_id) WHERE is_active;
+CREATE INDEX IF NOT EXISTS rooms_tags_gin ON public.rooms USING gin (tags);
+
+ALTER TABLE public.rooms ENABLE ROW LEVEL SECURITY;
+ALTER TABLE public.rooms FORCE ROW LEVEL SECURITY;
+
+DROP POLICY IF EXISTS rooms_member_all ON public.rooms;
+CREATE POLICY rooms_member_all ON public.rooms
+  TO authenticated
+  USING (tenant_id IN (SELECT public.user_tenant_ids()))
+  WITH CHECK (tenant_id IN (SELECT public.user_tenant_ids()));
+
+DROP TRIGGER IF EXISTS rooms_set_updated_at ON public.rooms;
+CREATE TRIGGER rooms_set_updated_at
+  BEFORE UPDATE ON public.rooms
+  FOR EACH ROW EXECUTE FUNCTION public.handle_updated_at();
+
+-- O EQUIPAMENTO passa a poder dizer em que sala está. Coluna nova e nula: os
+-- aparelhos já cadastrados continuam sem sala, que é a verdade sobre eles.
+ALTER TABLE public.products
+  ADD COLUMN IF NOT EXISTS room_id uuid REFERENCES public.rooms(id) ON DELETE SET NULL;
+
+COMMENT ON COLUMN public.products.room_id IS
+  'Para `kind = asset`: em que sala o equipamento está. Ver a 153.';

package/migrations/154_as_duas_tabelas_novas_dizem_de_quem_sao.sql

@@ -0,0 +1,33 @@
+-- ---------------------------------------------------------------------------
+-- 154 — `payee_accounts` e `rooms` declaram que são da BASE.
+--
+-- As duas nasceram sem prefixo, que é o certo: a regra (#285, ADR 0011) diz
+-- que `plg_x_*` marca plugin e um nome NU em `public` é da base. E as duas
+-- foram criadas em `packages/db/migrations`, que é a base.
+--
+-- O que ficou faltando foi a outra metade da regra. `app.base_owned_tables` é
+-- a lista que o verificador consulta para RECUSAR um plugin que tente criar um
+-- nome da base — foi ela que nasceu da vez em que plugin-forms criou
+-- `public.documents`, o financeiro criou `public.sequences` e a loja criou
+-- `public.shipping_zones`: três tabelas que leem como base e não são.
+--
+-- Sem a linha aqui, `public.rooms` está protegido por convenção outra vez, que
+-- é exatamente o que essa lista existe para substituir.
+--
+-- ── e por que as duas são da base, e não de um plugin ──────────────────
+--
+-- `rooms`: `public.products.room_id` aponta para ela — uma coluna de tabela da
+-- base. Se a sala fosse de um plugin, a base dependeria dele para existir. E
+-- `appointments`, `schedules` e `services` já são base: atendimento presencial
+-- não é um módulo opcional da espinha, é parte dela.
+--
+-- `payee_accounts`: é alcançada por `people` (base) e usada por três plugins
+-- diferentes — registry, workforce e financial. Uma tabela que três plugins
+-- leem e nenhum é dono é, por definição, da base.
+-- ---------------------------------------------------------------------------
+
+INSERT INTO app.base_owned_tables (table_name, note)
+VALUES
+  ('payee_accounts', 'Para onde o dinheiro SAI: conta e PIX de quem a casa paga. Não é conta do razão.'),
+  ('rooms', 'A sala, cadeira ou box onde se atende, dentro de uma unidade. Não é unidade: não tem caixa, estoque nem permissão própria.')
+ON CONFLICT (table_name) DO NOTHING;

package/migrations/155_o_pacote_tem_observacao_e_etiqueta_e_diz_de_quem_e.sql

@@ -0,0 +1,28 @@
+-- ---------------------------------------------------------------------------
+-- 155 — o pacote de serviços ganha o rail e entra na lista de nomes da base.
+--
+-- `service_packages` e `service_package_items` JÁ EXISTEM: vieram inteiras do
+-- porte do V1, com preço, sessões e validade. O que nunca existiu foi a TELA —
+-- e por isso elas estavam no quadro de paridade como «não existe», quando o
+-- que faltava era só a porta.
+--
+-- Esta migration faz duas coisas pequenas e nenhuma grande:
+--
+--   1. `notes` e `tags`, para o pacote ter o mesmo rail de todo cadastro.
+--   2. a linha em `app.base_owned_tables` — os dois nomes são nus em `public`
+--      e nada declarava que são da base, o mesmo furo que a 154 fechou para
+--      `rooms` e `payee_accounts`.
+-- ---------------------------------------------------------------------------
+
+ALTER TABLE public.service_packages
+  ADD COLUMN IF NOT EXISTS notes text,
+  ADD COLUMN IF NOT EXISTS tags text[] DEFAULT '{}'::text[];
+
+CREATE INDEX IF NOT EXISTS service_packages_tags_gin
+  ON public.service_packages USING gin (tags);
+
+INSERT INTO app.base_owned_tables (table_name, note)
+VALUES
+  ('service_packages', 'O conjunto de serviços vendido junto, com preço, número de sessões e validade.'),
+  ('service_package_items', 'Que serviços entram num pacote, e quantas vezes cada um.')
+ON CONFLICT (table_name) DO NOTHING;

package/migrations/156_restaurante_nao_vende_servico.sql

@@ -0,0 +1,44 @@
+-- ---------------------------------------------------------------------------
+-- 156_restaurante_nao_vende_servico.sql
+-- ---------------------------------------------------------------------------
+-- Um restaurante não tem "Serviços".
+--
+-- Cadastros abre com onze telas, e duas delas — Serviços e Categorias de
+-- Serviço — são do ofício de quem MARCA HORA: o salão, a clínica, o estúdio.
+-- Numa cozinha elas são duas linhas que nunca recebem um registro, e o preço
+-- não é o espaço: é que quem abre o menu procurando "onde cadastro o prato"
+-- lê "Serviços" antes de ler "Cardápio".
+--
+-- `preset.hide` é o `hideNav()` em forma de dado (083): rota que este ofício
+-- NÃO põe no rail. A tela continua existindo — o dia em que a casa abrir uma
+-- consultoria de cardápio, a rota está lá —, ela só deixa de ser oferecida a
+-- quem nunca a pediu.
+--
+-- ── O que isto NÃO resolve, e onde ──────────────────────────────────────────
+-- O tipo de linha "Serviço" do Financeiro não sai daqui, e não devia: acoplar
+-- o documento a uma rota do menu seria fazer o Financeiro conhecer o desenho
+-- do rail. Ele se resolve sozinho no aplicativo — um catálogo com zero linhas
+-- deixa de virar escolha (ver `useStockedItemTypes`), o que também acerta a
+-- loja e qualquer casa que receba o catálogo do pacote e não o use.
+--
+-- Só o `resto`: o `full` é o aplicativo central, que carrega o ofício de quem
+-- entrar e por isso não pode decidir isto por ninguém.
+--
+-- Idempotente: recalcula o `hide` a partir do que está lá.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps
+   SET preset = jsonb_set(
+         preset,
+         '{hide}',
+         (
+           SELECT to_jsonb(array_agg(rota ORDER BY rota))
+             FROM (
+               SELECT jsonb_array_elements_text(coalesce(preset -> 'hide', '[]'::jsonb)) AS rota
+               UNION
+               SELECT unnest(ARRAY['/registry/services', '/registry/categories'])
+             ) AS rotas
+         ),
+         true
+       )
+ WHERE id = 'resto';

package/migrations/157_o_que_a_porta_da_unidade_criou_tambem_se_revoga.sql

@@ -0,0 +1,45 @@
+-- ---------------------------------------------------------------------------
+-- 157_o_que_a_porta_da_unidade_criou_tambem_se_revoga.sql
+--
+-- ── a postura que voltou a ficar vermelha ───────────────────────────────
+--
+--     N15c: anon can execute nothing callable in schema app
+--           (trigger functions cannot be called directly)
+--
+-- A regra está escrita na 088, e é a mesma de sempre: **função nova nasce com
+-- `EXECUTE` para PUBLIC, e `anon` herda dali**. Não é preciso conceder nada
+-- para abrir a porta — é preciso REVOGAR para fechá-la, e quem esquece não vê
+-- erro nenhum.
+--
+-- Três migrations desta onda criaram função em `app` e nenhuma revogou:
+--
+--   140  app.trg_v_units_write          a porta de ESCRITA da vista de unidades
+--   141  app.parse_legacy_address       o endereço antigo virando estruturado
+--   142  app.trg_v_units_write          (redefinida)
+--
+-- `trg_v_units_write` é função de GATILHO, e é exatamente o caso que o nome da
+-- postura cita: gatilho não se chama direto. Ele roda como dono da vista, com
+-- `SECURITY DEFINER` — deixá-lo executável por `anon` é oferecer a porta de
+-- escrita da unidade a quem nem entrou na casa.
+--
+-- Por `proname` e não por assinatura: a 142 redefine a mesma função, e listar
+-- a assinatura deixaria a versão anterior para trás caso ela sobreviva em
+-- algum pool. O laço pega todas as sobrecargas que existirem.
+--
+-- Idempotente e replay-safe: revogar duas vezes é no-op, e um pool onde a
+-- função ainda não existe simplesmente não entra no laço.
+-- ---------------------------------------------------------------------------
+
+DO $$
+DECLARE v_fn text;
+BEGIN
+  FOR v_fn IN
+    SELECT p.oid::regprocedure::text
+      FROM pg_proc p JOIN pg_namespace n ON n.oid = p.pronamespace
+     WHERE n.nspname = 'app'
+       AND p.proname IN ('trg_v_units_write', 'parse_legacy_address')
+  LOOP
+    EXECUTE format('REVOKE ALL ON FUNCTION %s FROM PUBLIC, anon, authenticated', v_fn);
+    EXECUTE format('GRANT EXECUTE ON FUNCTION %s TO service_role', v_fn);
+  END LOOP;
+END $$;