@fayz-ai/db 0.14.0 → 0.16.0

package/migrations/106_a_comunidade_se_gere_como_escola.sql

@@ -0,0 +1,84 @@
+-- ---------------------------------------------------------------------------
+-- 088_a_comunidade_se_gere_como_escola.sql
+-- ---------------------------------------------------------------------------
+-- Duas coisas, e a segunda é consequência da primeira.
+--
+-- ── `hide`: o contrário de `under` ─────────────────────────────────────────
+-- Com o preset agrupando em vez de redesenhar (083), quem não fosse nomeado ia
+-- para o FIM em vez de sumir — regra que existe para um plugin novo não
+-- desaparecer em silêncio. Só que no ChefControl isso devolveu cinco linhas
+-- soltas embaixo de sete rubricas curadas: Agenda, CRM, Marketing, Automações,
+-- Comunicação.
+--
+-- Não era ruído: no vocabulário do ChefControl a Agenda É "Reservas" e o CRM É
+-- "Clientes". Mostrar os dois nomes é mostrar o mesmo módulo duas vezes. O
+-- resto-saas resolve isso com `hideNav()` em código; faltava a forma em dado.
+--
+-- `hide` são prefixos de rota que este ofício NÃO põe no rail. Aplicado ANTES
+-- das rubricas: uma rota calada não pode ser reivindicada nem sobrar no fim.
+--
+-- ── A escola passa a servir COMUNIDADE ─────────────────────────────────────
+-- IAM Club estava na bilheteria e as cinco contas dela — IAM, Great DJs, Crema
+-- Club, Airfryer Collective, Aldeia Zen — são a mesma forma: programa,
+-- encontro, membro, ingresso. Um clube se gere como comunidade, não como
+-- portaria de evento avulso.
+--
+-- `orders` entra na oferta porque O INGRESSO É UM PEDIDO. Não há plugin de
+-- `ticketing`, nem de `events`, nem de `community` — o que existe é `agenda`
+-- (o encontro), `orders` (o ingresso), `conversations` + `crm` (a comunidade).
+-- As rubricas usam as palavras do ramo; os módulos são os que existem.
+--
+-- O que isto NÃO decide: se "CommunityControl" merece ser um aplicativo
+-- próprio. Hoje cinco contas de comunidade rodam a escola porque a forma serve;
+-- o dia em que o vocabulário "aluno/turma" atrapalhar mais do que ajudar é o
+-- dia de separar, e aí é uma linha em `app.apps`.
+-- ---------------------------------------------------------------------------
+
+UPDATE app.apps SET preset = preset
+  || '{"hide":["/agenda","/sales","/marketing","/automations","/communication"]}'::jsonb
+ WHERE id = 'resto';
+
+UPDATE app.apps SET preset = preset || $$
+{
+  "modules": ["dashboard","admin","notifications","conversations","courses","agenda","orders",
+              "crm","financial","marketing","automations","reports","custom_forms"],
+  "rail": ["dashboard", "conversations",
+           { "label": "Programa",  "icon": "GraduationCap", "under": ["/courses"] },
+           { "label": "Encontros", "icon": "CalendarDays",  "under": ["/agenda", "/orders"] },
+           "crm", "marketing", "financial", "reports"],
+  "hide": ["/automations", "/communication"]
+}
+$$::jsonb WHERE id = 'school';
+
+-- IAM Club sai da bilheteria.
+UPDATE app.tenant_apps SET app_id = 'school', updated_at = now()
+ WHERE tenant_id = (SELECT id FROM public.tenants WHERE slug = 'iam-club') AND app_id = 'ticket';
+UPDATE public.tenants SET vertical_id = 'education', updated_at = now() WHERE slug = 'iam-club';
+DELETE FROM app.tenant_plugins
+ WHERE tenant_id = (SELECT id FROM public.tenants WHERE slug = 'iam-club')
+   AND plugin_id IN ('menu','inventory');
+
+-- O que uma comunidade liga.
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT t.id, p.plugin_id, '', 'active', 'manual'
+  FROM public.tenants t
+ CROSS JOIN (VALUES ('courses'),('agenda'),('orders'),('crm'),('conversations'),
+                    ('marketing'),('financial'),('reports')) AS p(plugin_id)
+ WHERE t.slug IN ('iam-club','crema-club','airfryer-collective','aldeia-zen','great-djs')
+ON CONFLICT (tenant_id, plugin_id, facet) DO UPDATE SET status = 'active', updated_at = now();
+
+-- A invariante da 087, de novo: oferecer mais do que se exige é o normal; o
+-- contrário nunca é.
+DO $$
+DECLARE v_bad text;
+BEGIN
+  SELECT string_agg(a.id || ' exige ' || r.m || ' e não oferece', '; ') INTO v_bad
+    FROM app.apps a CROSS JOIN LATERAL unnest(a.requires) AS r(m)
+   WHERE a.active
+     -- Ver a nota na 101: a verificação nomeia a divergência, não derruba a
+     -- cadeia por causa de uma forma que ela não esperava.
+     AND jsonb_typeof(a.preset->'modules') = 'array'
+     AND jsonb_array_length(a.preset->'modules') > 0
+     AND NOT (a.preset->'modules' ? r.m);
+  IF v_bad IS NOT NULL THEN RAISE EXCEPTION 'requires fora da oferta: %', v_bad; END IF;
+END $$;

package/migrations/107_o_logo_da_coluna_e_projecao_do_documento.sql

@@ -0,0 +1,53 @@
+-- ---------------------------------------------------------------------------
+-- 089_o_logo_da_coluna_e_projecao_do_documento.sql
+-- ---------------------------------------------------------------------------
+-- Great DJs e IAM Club tinham marca e apareciam SEM marca no seletor de contas.
+-- O motivo é velho conhecido nesta base: duas grafias do mesmo fato.
+--
+--   o seletor lê    v_team_members → tenants.logo_url        (coluna, de 2024)
+--   a marca mora em settings.branding.identity.logoUrl       (documento, 075)
+--
+-- Quem escreve a marca pela porta nova não toca na coluna velha, e a lista
+-- mostra iniciais. Sincronizar à mão criaria a terceira oportunidade de
+-- divergir — é o mesmo erro que a 074 já corrigiu uma vez para `primary_color`.
+--
+-- A coluna vira DERIVADA: um escritor (o documento), um gatilho, e todo leitor
+-- antigo segue funcionando sem saber que mudou de fonte.
+--
+-- `update OF settings` e não `update`: o gatilho existe para acompanhar a
+-- marca, e disparar em toda escrita da tabela o faria reescrever a coluna em
+-- cada troca de plano ou de nome.
+--
+-- ── E por que `markUrl` vem ANTES de `logoUrl` ─────────────────────────────
+-- Tudo que lê esta coluna desenha num SLOT QUADRADO: o seletor do rail, o
+-- escolhedor pós-login, a tela de troca — todos `OrgMark`, de h-5 a h-9. O
+-- Espaço Facial tem as duas artes, e a coluna pegou o wordmark horizontal: no
+-- quadrado ele virou "…aço|", um pedaço do meio da palavra. `markUrl` existe
+-- exatamente para esse lugar.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION app.sync_tenant_logo_url() RETURNS trigger
+LANGUAGE plpgsql AS $$
+BEGIN
+  NEW.logo_url := coalesce(
+    NEW.settings #>> '{branding,identity,markUrl}',   -- a arte QUADRADA
+    NEW.settings #>> '{branding,identity,logoUrl}',   -- o wordmark, se for só o que há
+    NEW.settings #>> '{branding,logo_url}',           -- a grafia anterior à 074
+    NEW.logo_url                                      -- ninguém disse nada: mantém
+  );
+  RETURN NEW;
+END $$;
+
+DROP TRIGGER IF EXISTS tenants_sync_logo_url ON public.tenants;
+CREATE TRIGGER tenants_sync_logo_url
+  BEFORE INSERT OR UPDATE OF settings ON public.tenants
+  FOR EACH ROW EXECUTE FUNCTION app.sync_tenant_logo_url();
+
+COMMENT ON COLUMN public.tenants.logo_url IS
+  'DERIVADA de settings.branding.identity.logoUrl pelo gatilho tenants_sync_logo_url (089). Leitores antigos — v_team_members, o seletor de contas — continuam lendo daqui; quem ESCREVE escreve no documento da marca.';
+
+-- Backfill. `set settings = settings` e não `set updated_at = now()`: o gatilho
+-- escuta a COLUNA settings, e tocar outra não o acorda.
+UPDATE public.tenants SET settings = settings
+ WHERE settings #>> '{branding,identity,markUrl}' IS NOT NULL
+    OR settings #>> '{branding,identity,logoUrl}' IS NOT NULL;

package/migrations/108_o_modulo_do_oficio_vizinho_tem_onde_ser_visto.sql

@@ -0,0 +1,78 @@
+-- ---------------------------------------------------------------------------
+-- 090_o_modulo_do_oficio_vizinho_tem_onde_ser_visto.sql
+-- ---------------------------------------------------------------------------
+-- A 079 deu ao ofício uma OFERTA (`app.apps.preset.modules`), e a tela de
+-- Módulos passou a mostrar só o que o ofício DESTA conta oferece. Isso está
+-- certo como padrão e errado como limite: um salão que resolveu vender online
+-- não tem, em lugar nenhum do produto, onde descobrir que `shop` existe. O
+-- catálogo acabou onde o ofício começou.
+--
+-- O que falta não é dado novo — é uma PORTA para o dado que já está lá. Sete
+-- linhas de `app.apps` dizem, cada uma, um ofício e o que ele oferece, e
+-- nenhum cliente consegue lê-las senão para a própria conta: `app_config()`
+-- só devolve os aplicativos que estão em `app.tenant_apps`.
+--
+-- ── Por que uma função nova, e não mais uma chave no app_config() ──────────
+-- `app_config()` é a chamada do BOOT — ela existe para a shell conseguir
+-- desenhar a primeira tela. O catálogo não participa disso: quem o lê é uma
+-- aba de Configurações, aberta por alguém que já entrou. Pendurá-lo ali é
+-- pagar o payload em todo login de todo usuário por uma tela que a maioria
+-- nunca abre.
+--
+-- E há o motivo prosaico: `normalizeAppConfig`, no @fayz-ai/core publicado,
+-- reconstrói a resposta chave a chave e descarta o que não conhece. Uma chave
+-- nova no `app_config()` só chegaria na tela depois de uma release do pacote —
+-- a tela ficaria esperando o trem errado.
+--
+-- ── Por que `mine` vem do servidor ─────────────────────────────────────────
+-- Quem lê precisa saber qual das rubricas é a DELE: é a que abre expandida, e
+-- é a diferença entre "o seu ofício, e o que mais existe" e uma lista de sete
+-- ofícios anônimos. A resposta depende da conta, e o servidor já sabe quem
+-- está perguntando. Devolver o catálogo cru e mandar o cliente cruzá-lo com
+-- `app_config().apps` seria criar a segunda grafia do mesmo fato — que é
+-- exatamente o que a 079 passou a migration inteira desfazendo.
+--
+-- Nada de permissão nova: o catálogo é o que o PRODUTO oferece, igual para
+-- todo mundo. O que a conta tem continua em `app.tenant_plugins`, e quem liga
+-- ou desliga continua sendo `tenant_plugin_set`, que já exige `settings.manage`
+-- e já impõe o teto do plano.
+-- ---------------------------------------------------------------------------
+
+CREATE OR REPLACE FUNCTION public.app_catalog()
+RETURNS jsonb
+LANGUAGE sql
+STABLE SECURITY DEFINER
+SET search_path TO ''
+AS $function$
+  SELECT coalesce(jsonb_agg(x ORDER BY x ->> 'name'), '[]'::jsonb)
+    FROM (
+      SELECT jsonb_build_object(
+               'id',          a.id,
+               'name',        a.name,
+               'vertical_id', a.vertical_id,
+               'modules',     coalesce(a.preset -> 'modules', '[]'::jsonb),
+               'mine',        EXISTS (
+                                SELECT 1 FROM app.tenant_apps ta
+                                 WHERE ta.app_id = a.id
+                                   AND ta.status = 'active'
+                                   AND ta.tenant_id = app.current_tenant_id())
+             ) AS x
+        FROM app.apps a
+       -- Sem ofício não é ofício: o control-admin é a casa, não uma rubrica.
+       -- Sem oferta não há o que listar — a linha existiria como categoria
+       -- vazia, que é uma pergunta sem resposta.
+       WHERE a.active
+         AND a.vertical_id IS NOT NULL
+         -- `jsonb_typeof` antes: um ofício cujo `modules` não for array ainda
+         -- não tem oferta, e uma função STABLE não é lugar de levantar exceção.
+         AND jsonb_typeof(a.preset -> 'modules') = 'array'
+         AND jsonb_array_length(a.preset -> 'modules') > 0
+    ) c;
+$function$;
+
+REVOKE ALL ON FUNCTION public.app_catalog() FROM public;
+GRANT EXECUTE ON FUNCTION public.app_catalog() TO authenticated;
+GRANT EXECUTE ON FUNCTION public.app_catalog() TO service_role;
+
+COMMENT ON FUNCTION public.app_catalog() IS
+  'O catálogo por OFÍCIO (090): cada aplicativo ativo com id, nome, vertical_id, a oferta dele (preset.modules) e `mine` — se esta conta o roda. Lida pelo marketplace de Módulos para agrupar o que existe por categoria de ofício; o que a conta TEM continua em app_config().plugins.';

package/migrations/109_a_conta_diz_o_que_nao_usa_e_a_marca_pinta_a_casa.sql

@@ -0,0 +1,67 @@
+-- ---------------------------------------------------------------------------
+-- 091_a_conta_diz_o_que_nao_usa_e_a_marca_pinta_a_casa.sql
+-- ---------------------------------------------------------------------------
+-- Eu semeei as cinco contas de comunidade com os mesmos oito módulos — exatamente
+-- o que esta arquitetura existe para não fazer. O founder corrigiu olhando a
+-- tela: Crema Club não vende curso; Airfryer não tem curso nem conversas.
+--
+-- Ditas, não omitidas. Uma linha `disabled` é a conta AFIRMANDO que não usa o
+-- módulo; omitir cairia no padrão do manifesto, que é ligado. E a rubrica some
+-- sozinha: "Programa" não desenha numa casa sem curso, porque uma rubrica sem
+-- filho ativo não é desenhada (ver rail-preset).
+-- ---------------------------------------------------------------------------
+
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT t.id, p.plugin_id, '', 'disabled', 'manual'
+  FROM public.tenants t
+  JOIN (VALUES
+    ('crema-club',          'courses'),
+    ('airfryer-collective', 'courses'),
+    ('airfryer-collective', 'conversations')
+  ) AS p(slug, plugin_id) ON p.slug = t.slug
+ON CONFLICT (tenant_id, plugin_id, facet) DO UPDATE SET status = 'disabled', updated_at = now();
+
+-- ── Espaço Renova: canvas marrom, conteúdo claro ───────────────────────────
+-- Quatro tentativas, e as três primeiras erraram no MESMO ponto: eu escurecia
+-- `surface.background` esperando ver o papel de fundo mudar, e ele não mudava.
+--
+-- O motivo está no shell, não na marca. Com a moldura ligada, o que aparece
+-- ATRÁS dela é `bg-sidebar` — `AppShell` pinta o vão com a cor do rail
+-- (`frame && 'md:bg-sidebar'`). Então, para uma marca:
+--
+--   rail.background     é o rail E o canvas atrás da moldura
+--   surface.background  é a superfície DENTRO da moldura, onde mora o texto
+--
+-- Com isso o pedido é direto: o marrom vai no rail, o conteúdo volta a ser
+-- claro com tinta escura, e nenhum texto fica sobre um fundo da própria cor.
+-- A primária é o marrom AMOSTRADO da arte oficial do cliente (#935427), não uma
+-- interpretação minha do logo. O creme da arte (#FFFAEA) ficou só no ladrilho:
+-- ele é a cor do desenho, não a da casa.
+--
+-- E `surface` SAI do documento em vez de receber um branco escolhido por mim.
+-- Sem a chave, a marca não opina sobre a superfície e o app usa o tema dele —
+-- que é diferente de eu escrever outro hex claro, porque qualquer hex seria
+-- mais uma opinião, e o pedido era não ter opinião nenhuma ali.
+--
+-- ── Armadilha que me custou três recargas ─────────────────────────────────
+-- O tema lê a marca do SNAPSHOT DA ORGANIZAÇÃO (`fayz:org-snapshot`), não do
+-- snapshot de configuração (`fayz:app-config:<tenant>`). Limpar um não limpa o
+-- outro, e eu fiquei vendo o creme antigo depois de já o ter removido do banco.
+-- Mesma família do TTL de 5 min que já escondeu mudança de trial antes.
+UPDATE public.tenants SET settings = jsonb_set(settings, '{branding,tokens}', $$
+{
+  "color":  { "primary": "#935427", "accent": "#B0743F" },
+  "rail":   { "background": "#2A201A", "foreground": "#F7F2EC", "border": "#3E3125",
+              "accent": "#3E3125", "accentForeground": "#D9A87C", "muted": "#B3A192" },
+  "radius": "0.75rem"
+}
+$$::jsonb), updated_at = now()
+ WHERE name = 'Espaco Renova Rio';
+
+-- O ladrilho quadrado, agora sobre o marrom da marca em vez de preto.
+UPDATE public.tenants t SET settings = jsonb_set(t.settings, '{branding,identity}',
+  coalesce(t.settings #> '{branding,identity}', '{}'::jsonb) || jsonb_build_object(
+    'logoUrl', 'https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/947b0ed0-82ad-4b99-88d0-b503a7ad09c2/branding/tile.png',
+    'markUrl', 'https://klvfxzreepavcpyjiwla.supabase.co/storage/v1/object/public/avatars/947b0ed0-82ad-4b99-88d0-b503a7ad09c2/branding/tile.png')
+), updated_at = now()
+ WHERE t.name = 'Espaco Renova Rio';

package/migrations/110_a_tabela_de_ramos_aprende_o_vocabulario_fechado.sql

@@ -0,0 +1,60 @@
+-- A tabela de ramos aprende o vocabulário que a conta passou a falar
+--
+-- A 093 fechou `tenants.vertical_id` em sete nomes e deixou órfão um caminho
+-- que ninguém olhou: o gatilho `tenants_apply_vertical_defaults`, que roda a
+-- cada INSERT em `public.tenants` e cruza `app.vertical_defaults` POR ESSE
+-- MESMO NOME. A tabela de ramos fala o vocabulário antigo:
+--
+--     app.vertical_defaults   agency, ecommerce, restaurant, salon, school
+--     tenants.vertical_id     food, beauty, commerce, education, events,
+--                             accounting, generic
+--
+-- A interseção é VAZIA. Desde a 093, toda conta nova nasce sem módulo nenhum
+-- semeado — e em silêncio, porque o gatilho engole a falha de propósito (uma
+-- conta sem módulos se conserta num clique; uma conta que não foi criada é um
+-- cadastro perdido). O sintoma some no warning e a conta chega vazia.
+--
+-- Isto não reabre a decisão da 093. `preset.modules` cruzado com
+-- `tenant_plugins` continua sendo quem decide o que aparece; esta tabela é só
+-- o ponto de partida de quem acabou de nascer. O conserto é traduzir as
+-- dezesseis linhas para o vocabulário fechado, não criar uma oitava grafia.
+--
+--     restaurant -> food        salon  -> beauty      school -> education
+--     ecommerce  -> commerce    agency -> generic
+--
+-- `events` e `accounting` ficam sem linha, e isso é a resposta honesta: a
+-- bilheteria e a contabilidade nunca tiveram default nenhum aqui, e inventar
+-- um agora seria adivinhar.
+--
+-- Idempotente: insere o traduzido e só então apaga o original.
+
+INSERT INTO app.vertical_defaults (vertical_id, plugin_id, facet, note)
+SELECT v.novo, d.plugin_id, d.facet, d.note
+  FROM app.vertical_defaults d
+  JOIN (VALUES
+    ('restaurant', 'food'),
+    ('salon',      'beauty'),
+    ('ecommerce',  'commerce'),
+    ('school',     'education'),
+    ('agency',     'generic')
+  ) AS v(velho, novo) ON v.velho = d.vertical_id
+ON CONFLICT (vertical_id, plugin_id, facet) DO NOTHING;
+
+DELETE FROM app.vertical_defaults
+ WHERE vertical_id IN ('restaurant','salon','ecommerce','school','agency');
+
+-- O que sobrou fala o vocabulário fechado, e nada mais.
+DO $$
+DECLARE v_fora text[];
+BEGIN
+  SELECT array_agg(DISTINCT vertical_id) INTO v_fora
+    FROM app.vertical_defaults
+   WHERE vertical_id NOT IN
+     ('food','beauty','commerce','education','events','accounting','generic');
+  IF v_fora IS NOT NULL THEN
+    RAISE EXCEPTION 'app.vertical_defaults ainda fala fora do vocabulario: %', v_fora;
+  END IF;
+END $$;
+
+COMMENT ON TABLE app.vertical_defaults IS
+  'O que uma conta NOVA daquele ramo já nasce com. Mesmo vocabulário de tenants.vertical_id (093). Ponto de partida, não portão: quem decide o que aparece é app.apps.preset.modules cruzado com app.tenant_plugins.';

package/migrations/111_o_erp_generico_nao_vende_por_pedido.sql

@@ -0,0 +1,50 @@
+-- ---------------------------------------------------------------------------
+-- 108_o_erp_generico_nao_vende_por_pedido.sql
+-- ---------------------------------------------------------------------------
+-- O ControlGroup é o ERP genérico: ele roda o `full` e o `fiscal`, e a empresa
+-- atendida por ele não vende por PEDIDO. A venda dela é orçamento, contrato e
+-- título — o funil do CRM e o razão do financeiro. "Pedidos" no rail é uma
+-- tela que ninguém daquela casa abre, e que ainda promete um fluxo de balcão
+-- que não existe ali.
+--
+-- ── Por que a linha está lá, se o ofício não a oferece ─────────────────────
+-- `app.apps.preset.modules` do `full` e do `fiscal` não citam `orders`. O
+-- portão da oferta (resolvePluginRuntime) pularia o plugin por isso — MENOS
+-- quando existe uma linha `active` explícita, que é o caso do módulo vendido à
+-- parte e vence a oferta. É uma dessas linhas, resíduo de quando a conta
+-- recebeu aplicativo que não era o dela, que está desenhando "Pedidos".
+--
+-- ── Por que aqui, e não no preset do ofício ────────────────────────────────
+-- Tirar `orders` de `app.apps.preset` tiraria Pedidos de TODA conta que roda o
+-- mesmo aplicativo. O que muda é o que ESTA conta usa, e isso mora na camada
+-- do meio: o ofício propõe, a conta dispõe.
+--
+-- ── Dita, não omitida ──────────────────────────────────────────────────────
+-- Apagar a linha devolveria o plugin ao padrão do manifesto, que é
+-- `defaultEnabled: true`. O runtime é aditivo: silêncio é "sim". Só um
+-- `disabled` explícito é a conta AFIRMANDO que não usa o módulo.
+--
+-- ── É `orders`, não `shop` ─────────────────────────────────────────────────
+-- Os dois plugins desenham `/orders` e os dois chamam a linha de "Pedidos", e
+-- desligar o errado não mudaria nada na tela. Quem desenha aqui é `orders`:
+-- `shop` contribui QUATRO rubricas juntas — Pedidos, Produtos, Conteúdo e
+-- Descontos —, e é assim que ele aparece na PULSE. O rail do ControlGroup não
+-- tem vitrine nenhuma; `orders` contribui uma linha só, e é a linha que sobra.
+--
+-- O Cardápio vai junto, e de propósito: `orders` declara `dependencies:
+-- ['menu']` e o runtime acende a dependência por arrasto. Sem quem o puxasse,
+-- `menu` volta a ficar fora da oferta e sai do rail sozinho.
+--
+-- ── Escrito na tabela, e não por `tenant_plugin_set` ───────────────────────
+-- A porta é a certa para o produto: ela exige `settings.manage` e impõe o teto
+-- do plano. Uma migration roda sem usuário — não há a quem pedir permissão —,
+-- então ela escreve a mesma linha que a porta escreveria, como fez a 105.
+-- ---------------------------------------------------------------------------
+
+-- Por `slug`: num banco vazio nenhuma linha casa e a migration não faz nada,
+-- em vez de estourar procurando uma conta que ainda não nasceu.
+INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, source)
+SELECT t.id, 'orders', '', 'disabled', 'manual'
+  FROM public.tenants t
+ WHERE t.slug = 'controlgroup'
+ON CONFLICT (tenant_id, plugin_id, facet) DO UPDATE SET status = 'disabled', updated_at = now();