@fayz-ai/db 0.28.1 → 0.29.1

package/migrations/213_the_department_is_a_declared_grouping.sql

@@ -0,0 +1,9 @@
+-- 213: the department is a declared grouping. V1's Cadastros › Departamentos
+-- (Financeiro, Cozinha, Marketing…) is an area of the company: it owns cost
+-- centres and the people whose record points at it. In V2 it is one more
+-- species of the category archetype, next to `staff_team` (139) — same table,
+-- same shape — so the registry can write it without a 23503 on save.
+-- Idempotent: `register_kind` is an upsert by species.
+
+SELECT public.register_kind('category', 'staff_department', 'registry', NULL, NULL,
+  'A department of the company — the area that owns cost centres and the people whose record points at it (Financeiro, Cozinha, Marketing).');

package/migrations/218_the_journey_is_offered_to_every_kitchen.sql

@@ -0,0 +1,72 @@
+-- 218: the getting-started journey reaches a new kitchen.
+--
+-- The plugin ships in the app bundle, but `app.apps.preset.modules` (097) is the
+-- OFFER: a module no trade offers stays out of the runtime even when it is born
+-- `defaultEnabled` (resolvePluginRuntime). The resto preset never listed
+-- `getting-started`, so every new restaurant landed on the generic checklist —
+-- no "Sua loja no ar" card, no "Teste grátis" tab, no "Iniciar teste" CTA.
+--
+-- Four additive, idempotent steps:
+--   1. every food trade offers the module;
+--   2. a food tenant is BORN with the binding — `app.vertical_defaults` is what
+--      `tenant_apply_vertical_defaults` reads inside `create_tenant` (010/113),
+--      so this holds with or without the client doing anything;
+--   3. the onboarding is never behind the plan ceiling: every plan that lists
+--      grants gets `getting-started` as included (plan_permits is what both
+--      the defaults and tenant_plugin_set check);
+--   4. the food tenants that already exist get the binding, source 'default'.
+--
+-- Nothing is removed, no tenant row other than a new binding is written.
+
+-- ── 1. The trade offers the journey ───────────────────────────────────────────
+-- Only where the offer is already an explicit, non-empty list. An app with no
+-- `modules` (or an empty one) offers EVERYTHING it compiles (runtime rule);
+-- writing a one-item list there would turn "all" into "only this".
+UPDATE app.apps
+   SET preset = jsonb_set(preset, '{modules}',
+                          (preset -> 'modules') || '["getting-started"]'::jsonb)
+ WHERE (id = 'resto' OR vertical_id = 'food')
+   AND jsonb_typeof(preset -> 'modules') = 'array'
+   AND jsonb_array_length(preset -> 'modules') > 0
+   AND NOT (preset -> 'modules' ? 'getting-started');
+
+DO $$
+DECLARE
+  v_plan text;
+BEGIN
+  -- ── 2. A food tenant is born with it ──────────────────────────────────────
+  IF to_regclass('app.vertical_defaults') IS NOT NULL THEN
+    INSERT INTO app.vertical_defaults (vertical_id, plugin_id, facet, note)
+    VALUES ('food', 'getting-started', '',
+            'The store-live journey: hours, payments, menu, test order and the trial clock (218).')
+    ON CONFLICT (vertical_id, plugin_id, facet) DO NOTHING;
+  END IF;
+
+  -- ── 3. Never behind the ceiling ───────────────────────────────────────────
+  -- A plan with no grants permits everything (plan_permits); a plan WITH grants
+  -- permits only what is listed, and the onboarding has to be on that list.
+  IF to_regprocedure('public.register_plan_grant(text,text,text,text,text)') IS NOT NULL
+     AND to_regclass('app.plan_grants') IS NOT NULL THEN
+    FOR v_plan IN SELECT DISTINCT g.plan_id FROM app.plan_grants g LOOP
+      IF NOT EXISTS (SELECT 1 FROM app.plan_grants x
+                      WHERE x.plan_id = v_plan AND x.plugin_id = 'getting-started' AND x.facet = '') THEN
+        PERFORM public.register_plan_grant(v_plan, 'getting-started', '', 'included',
+          'The onboarding journey is never behind the plan ceiling (218).');
+      END IF;
+    END LOOP;
+  END IF;
+
+  -- ── 4. The kitchens that already exist ────────────────────────────────────
+  -- Same shape as 203: a direct insert, because tenant_plugin_set resolves the
+  -- tenant from the session and a migration has none. A row that is already
+  -- there — active or deliberately disabled — is left exactly as it is.
+  IF to_regclass('app.tenant_plugins') IS NOT NULL AND to_regclass('app.tenant_apps') IS NOT NULL THEN
+    INSERT INTO app.tenant_plugins (tenant_id, plugin_id, facet, status, config, source)
+    SELECT DISTINCT ta.tenant_id, 'getting-started', '', 'active', '{}'::jsonb, 'default'
+      FROM app.tenant_apps ta
+      JOIN app.apps a ON a.id = ta.app_id
+     WHERE ta.status = 'active'
+       AND (a.id = 'resto' OR a.vertical_id = 'food')
+    ON CONFLICT (tenant_id, plugin_id, facet) DO NOTHING;
+  END IF;
+END $$;

package/migrations/219_a_faya_gere_seus_clientes.sql

@@ -0,0 +1,31 @@
+-- 219: the Faya manages its customers from inside GoControl.
+--
+-- One additive, idempotent step for plugin-customer-success: `customer-success`
+-- as an OPTIONAL grant on every plan that lists grants, so plan_permits never
+-- blocks tenant_plugin_set for the Faya's workspace. Optional, not included: the
+-- plugin is installed on one tenant by configuration
+-- (scripts/customer-success-enable.mjs), never by plan.
+--
+-- The "Gestão de clientes" rail group is NOT a preset rubric: the plugin declares
+-- the group line itself and the shell nests its sub-paths (and the helpdesk
+-- console, which the app routes under /customers). A rubric in preset.rail
+-- claiming one row would flatten that row and drop its children (rail-preset).
+--
+-- No tenant row is written.
+
+DO $$
+DECLARE
+  v_plan text;
+BEGIN
+  -- ── Never behind the plan ceiling ──────────────────────────────────────
+  IF to_regprocedure('public.register_plan_grant(text,text,text,text,text)') IS NOT NULL
+     AND to_regclass('app.plan_grants') IS NOT NULL THEN
+    FOR v_plan IN SELECT DISTINCT g.plan_id FROM app.plan_grants g LOOP
+      IF NOT EXISTS (SELECT 1 FROM app.plan_grants x
+                      WHERE x.plan_id = v_plan AND x.plugin_id = 'customer-success' AND x.facet = '') THEN
+        PERFORM public.register_plan_grant(v_plan, 'customer-success', '', 'optional',
+          'The Faya''s customer console: installed per tenant by configuration, never by plan (219).');
+      END IF;
+    END LOOP;
+  END IF;
+END $$;

package/migrations/220_a_test_order_is_not_a_sale_the_platform_hears_about.sql

@@ -0,0 +1,66 @@
+-- 220: a test order is not a sale the platform hears about.
+--
+-- `trg_orders_emit_completed` emits `order.completed` whenever an order
+-- closes, and that is how inventory consumes the recipe, notifications tell
+-- the customer and automations fire. The onboarding's "pedido de teste"
+-- (`orders.metadata.test = true`) also closes — and it is not a sale: it
+-- exists to prove that ticket, kitchen and till talk to each other. Taking
+-- stock out of the house for it, or messaging a customer who does not exist,
+-- is the same lie 072 stopped for the port: describing something that did
+-- not happen as if it had.
+--
+-- The smallest safe change is at the source, as in 072: the fact stays in
+-- `public.orders` (the journey reads it from there — `getting_started_minimums`
+-- and the PDV's own sensor), only the announcement is skipped. Every
+-- subscriber (inventory, notifications, automations) stays untouched and
+-- never sees a test; a subscriber that one day WANTS the test can read the
+-- table, which is where the truth is.
+--
+-- Idempotent.
+
+CREATE OR REPLACE FUNCTION public.trg_orders_emit_completed()
+ RETURNS trigger
+ LANGUAGE plpgsql
+ SECURITY DEFINER
+ SET search_path TO ''
+AS $function$
+BEGIN
+  -- O porte escreve com `migration.writer = 'on'` (072): um pedido que ele
+  -- fecha é um fato ANTIGO chegando agora.
+  IF coalesce(current_setting('migration.writer', true), '') = 'on' THEN
+    RETURN NULL;
+  END IF;
+
+  IF NEW.status IS DISTINCT FROM 'completed' THEN
+    RETURN NULL;
+  END IF;
+  IF TG_OP = 'UPDATE' AND OLD.status IS NOT DISTINCT FROM 'completed' THEN
+    RETURN NULL;
+  END IF;
+
+  -- A test order (220) is not a sale: no stock moves, no customer is told.
+  IF coalesce(NEW.metadata, '{}'::jsonb) @> '{"test":true}'::jsonb THEN
+    RETURN NULL;
+  END IF;
+
+  PERFORM public.plg_emit_event(
+    'order.completed',
+    jsonb_build_object(
+      'order_id',  NEW.id,
+      'kind',      NEW.kind,
+      'unit_id',   NEW.unit_id,
+      'party_id',  NEW.party_id,
+      'total',     NEW.total
+    ),
+    'order',
+    NEW.id::text,
+    NEW.tenant_id,
+    NULL
+  );
+  RETURN NULL;
+END $function$;
+
+COMMENT ON FUNCTION public.trg_orders_emit_completed() IS
+  'Avisa a plataforma que uma venda fechou. Silencioso quando quem fecha é o '
+  'porte (migration.writer = on, 072) e quando o pedido é um pedido de teste '
+  '(metadata.test, 220): nenhum dos dois é uma venda que acabou de acontecer.';

package/migrations/221_the_trial_clock_is_read_only_for_the_browser_for_real.sql

@@ -0,0 +1,57 @@
+-- 221: the trial clock is read-only for the browser — for real this time.
+--
+-- `tenants_trial_is_readonly` (000 baseline) is the BEFORE UPDATE trigger
+-- that keeps `tenants.trial_ends_at` out of the client's hands: the gateway's
+-- webhook (service_role) and the operator on psql/Management API (postgres)
+-- may move the date, the browser may not. Its body, as it stands today:
+--
+--     IF auth.role() = 'service_role' OR current_user IN ('postgres', 'supabase_admin') THEN
+--       RETURN NEW;
+--     END IF;
+--     -- otherwise: NEW.trial_ends_at := OLD.trial_ends_at
+--
+-- and the function is SECURITY DEFINER. That is the hole: inside a DEFINER
+-- function `current_user` IS THE OWNER — postgres on every pool — whoever the
+-- session is. So the bypass branch is always true, for a tenant admin doing a
+-- plain `UPDATE tenants SET trial_ends_at = …` through PostgREST as much as
+-- for the operator. `tenants_update` lets `is_tenant_admin` write the row, so
+-- the admin of any tenant could extend their own trial by one UPDATE. The
+-- journey (getting-started 001) and the design (decision 1) both assume this
+-- gate works.
+--
+-- The fix is to stop running as the owner. As SECURITY INVOKER the trigger
+-- sees the real context: a browser UPDATE runs as `authenticated` (blocked);
+-- the operator on psql runs as `postgres` (through); the webhook carries the
+-- service_role claim (through); and the plugin's own DEFINER RPCs
+-- (`getting_started_start_trial`, `getting_started_trial_set`) execute their
+-- UPDATE as their owner, postgres, so `current_user` inside the trigger is
+-- postgres there too (through) — which is exactly the sanctioned path.
+-- `session_user` alone would NOT do: through PostgREST it is always
+-- `authenticator`, so it would also block those RPCs and silently revert the
+-- date they just wrote. It is kept as a second bypass for a direct session.
+--
+-- Idempotent: CREATE OR REPLACE on the function; the trigger binding stays.
+
+CREATE OR REPLACE FUNCTION public.tenants_trial_is_readonly() RETURNS trigger
+    LANGUAGE plpgsql SECURITY INVOKER
+    SET search_path TO 'public'
+    AS $$
+BEGIN
+  -- service_role (gateway webhook) passes by claim. A direct operator session
+  -- (psql, Management API) passes by role. A DEFINER RPC owned by postgres
+  -- passes because, under INVOKER, this trigger inherits ITS context — while
+  -- a plain client UPDATE arrives as `authenticated` and is held.
+  IF auth.role() = 'service_role'
+     OR session_user IN ('postgres', 'supabase_admin')
+     OR current_user IN ('postgres', 'supabase_admin') THEN
+    RETURN NEW;
+  END IF;
+  IF NEW.trial_ends_at IS DISTINCT FROM OLD.trial_ends_at THEN
+    NEW.trial_ends_at := OLD.trial_ends_at;
+  END IF;
+  RETURN NEW;
+END;
+$$;
+
+COMMENT ON FUNCTION public.tenants_trial_is_readonly() IS
+  'Keeps tenants.trial_ends_at out of the browser''s hands. SECURITY INVOKER on purpose (221): as DEFINER, current_user was always the owner and the gate let every client UPDATE through. service_role, a direct postgres session and the plugin''s DEFINER RPCs pass; a plain authenticated UPDATE keeps the old date.';

package/migrations/224_a_quote_line_answers_to_the_quote.sql

@@ -0,0 +1,65 @@
+-- 223: a quote's line answers to the quote.
+--
+-- 207 made public.items ask the permission of the document a line belongs to,
+-- but it only named invoice and fulfillment: `parent_kind = 'quote'` fell into
+-- the ELSE and asked orders.*. A seller on the CRM (crm.quotes.*, no orders.*)
+-- opened a proposal and saw "Itens 0" — the lines were there, the quote list and
+-- the PDF (which read the snapshot in metadata) were right, and the detail,
+-- which reads public.items by quote_id, came back empty. The same seller could
+-- not save a quote with lines either: plugin-crm inserts/deletes them from the
+-- browser (data/supabase.ts, create and update).
+--
+-- A quote line now asks crm.quotes.*, the vocabulary public.quotes itself
+-- uses. Changing a line IS editing the quote — the editor replaces the lines
+-- (delete + insert) on every save — so:
+--   read    crm.quotes.read
+--   create  crm.quotes.create OR crm.quotes.edit   (a new quote, or an edit)
+--   edit    crm.quotes.edit
+--   delete  crm.quotes.edit OR crm.quotes.delete   (dropping a line on edit)
+-- Deleting the quote itself cascades by FK and never reaches these policies.
+-- order / invoice / fulfillment lines render exactly as 207 left them: same
+-- CASE, same permissions. orders.* no longer reads a quote line — it never
+-- read the quote it hangs from (quotes_authz_select asks crm.quotes.read), and
+-- crm_quote_convert is SECURITY DEFINER with its own crm.quotes.edit check.
+--
+-- No helper is SECURITY DEFINER here: scaffold_line_perm_sql only renders text;
+-- scaffold_refresh_policies keeps 207's body and is not redefined.
+-- Additive and idempotent: CREATE OR REPLACE + DROP POLICY IF EXISTS / CREATE.
+
+CREATE OR REPLACE FUNCTION app.scaffold_line_perm_sql(p_action text)
+  RETURNS text
+  LANGUAGE sql IMMUTABLE
+  SET search_path TO ''
+  AS $$
+  SELECT format(
+    '(CASE parent_kind WHEN %L THEN %s ELSE (select app.has_permission(CASE parent_kind WHEN %L THEN %L WHEN %L THEN %L ELSE %L END, unit_id)) END)',
+    'quote',
+    CASE p_action
+      WHEN 'create' THEN '((select app.has_permission(''crm.quotes.create'', unit_id)) OR (select app.has_permission(''crm.quotes.edit'', unit_id)))'
+      WHEN 'delete' THEN '((select app.has_permission(''crm.quotes.edit'', unit_id)) OR (select app.has_permission(''crm.quotes.delete'', unit_id)))'
+      ELSE format('(select app.has_permission(%L, unit_id))', 'crm.quotes.' || p_action)
+    END,
+    'invoice', 'financial.' || p_action, 'fulfillment', 'inventory.' || p_action, 'orders.' || p_action);
+$$;
+REVOKE ALL ON FUNCTION app.scaffold_line_perm_sql(text) FROM PUBLIC;
+GRANT ALL ON FUNCTION app.scaffold_line_perm_sql(text) TO service_role;
+
+COMMENT ON FUNCTION app.scaffold_line_perm_sql(text) IS
+  'Renders the permission check of a public.items policy from the line''s document (#207, #223): quote → crm.quotes.* (create/delete also accept crm.quotes.edit — changing a line is editing the quote), invoice → financial.*, fulfillment → inventory.*, order → orders.*.';
+
+-- select / update / delete: the 207 generator, which renders from the function above.
+SELECT app.scaffold_refresh_policies('public.items')
+ WHERE EXISTS (SELECT 1 FROM app.scaffold_registry WHERE table_schema = 'public' AND table_name = 'items');
+
+-- insert: scaffold_refresh_policies does not render it, so it is rebuilt here
+-- with the template's shape (scaffold_table) and the line's permission.
+DO $$
+BEGIN
+  IF to_regclass('public.items') IS NULL THEN
+    RETURN;
+  END IF;
+  EXECUTE 'DROP POLICY IF EXISTS items_authz_insert ON public.items';
+  EXECUTE format(
+    'CREATE POLICY items_authz_insert ON public.items FOR INSERT TO authenticated WITH CHECK (tenant_id = (select app.current_tenant_id()) AND (unit_id IS NULL OR (select app.has_unit(unit_id))) AND %s)',
+    app.scaffold_line_perm_sql('create'));
+END $$;

package/package.json

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