@fayz-ai/plugin-notifications 0.2.2 → 0.2.3

package/dist/index.js

@@ -1322,9 +1322,269 @@ REVOKE ALL ON FUNCTION public.notifications_history_summary(integer) FROM PUBLIC
 GRANT EXECUTE ON FUNCTION public.notifications_history_summary(integer) TO authenticated;
 GRANT EXECUTE ON FUNCTION public.notifications_history_summary(integer) TO service_role;
 `;
+var MIGRATION_002_THE_OPT_OUT_IS_CHECKED_BY_PHONE = `-- 002_the_opt_out_is_checked_by_phone.sql
+--
+-- THE OPT-OUT WAS NEVER CHECKED, AND SAID SO ONLY IN A NOTICE.
+--
+-- \`notifications_resolve_channel\` opens with the strongest comment in the
+-- plugin: the opt-out "is absolute and is checked first \u2026 no template, purpose
+-- or preference of ours outranks it." It then read a column that does not
+-- exist. \`plg_conversations_optouts\` is keyed by \`phone_e164\` \u2014 there is no
+-- \`person_id\` on it and there never was, because the record arrives from a
+-- WhatsApp webhook that knows a phone number and nothing else.
+--
+-- The query therefore raised 42703 on EVERY call. A blanket
+-- \`EXCEPTION WHEN OTHERS\` caught it, set \`v_optout := false\` and continued. So
+-- the absolute check returned "not opted out" for everybody, always, and the
+-- only trace was a NOTICE nobody reads.
+--
+-- Two things are wrong there and both are fixed here.
+--
+-- 1. THE LOOKUP. The opt-out is about a phone; the queue targets a person. The
+--    bridge is \`people.phone\`, which is free text \u2014 a direct comparison against
+--    an E.164 column would match almost nothing and would be the same silent
+--    failure wearing a different coat. \`notifications_phone_key\` reduces both
+--    sides to the same national digits, following the convention
+--    \`plg_conversations_match_by_phone\` already established for this exact
+--    problem: strip everything that is not a digit, drop a leading country
+--    code, and repair a legacy 10-digit Brazilian mobile by restoring the 9.
+--    It compares the WHOLE national number rather than \`right(digits, 10)\`,
+--    because the last ten digits of an 11-digit national number drop the first
+--    digit of the area code and collide across DDDs \u2014 11 and 21 produce the
+--    same key. For matching a thread that is a tolerable bet; for deciding
+--    whether someone asked to be left alone it is not.
+--
+-- 2. THE FAILURE DIRECTION. Consent fails CLOSED now. If the table is there and
+--    the read fails for a reason this version does not understand, the message
+--    is blocked with a reason rather than sent. A blocked message is a row on
+--    the history screen with the reason next to it, and somebody can act on it;
+--    a message sent to someone who asked to stop cannot be recalled. The
+--    \`to_regclass\` guard stays as it was: a pool without plugin-conversations
+--    has no opt-out records, which is an answer, not an error.
+--
+-- What is deliberately NOT changed: the check stays ABSOLUTE rather than
+-- becoming per-channel. \`plg_conversations_optouts.channel\` would allow "he
+-- stopped WhatsApp, e-mail is still fine", and that may well be what the
+-- business wants \u2014 but it loosens consent, and loosening consent is a product
+-- decision, not a bug fix. Over-blocking is the safe direction to be wrong in.
+--
+-- Scope of the damage until now: the queue's \`whatsapp\` sender only writes a
+-- \`queued\` row into \`plg_conversation_messages\` and nothing in the repo drains
+-- it, and the edge function \`messaging-send\` checks the opt-out correctly by
+-- phone on its own path. So this was a live hole in the QUEUE, which is exactly
+-- what any future outbound cadence would be built on.
+
+SET check_function_bodies = false;
+
+-- \u2500\u2500 function \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
+
+-- The comparable form of a phone number: national digits, country code gone,
+-- legacy mobile repaired. NULL when the input cannot be a phone number, so that
+-- a person with no phone can never accidentally equal an opt-out row.
+CREATE OR REPLACE FUNCTION public.notifications_phone_key(p_phone text)
+RETURNS text
+LANGUAGE plpgsql IMMUTABLE
+SET search_path TO ''
+AS $$
+DECLARE d text; national text;
+BEGIN
+  d := regexp_replace(coalesce(p_phone, ''), '[^0-9]', '', 'g');
+  IF d = '' THEN RETURN NULL; END IF;
+
+  -- A leading 55 is the country code only when something remains that could be
+  -- a national number; '5511' is a landline in DDD 55, not a country code.
+  national := CASE WHEN length(d) > 11 AND left(d, 2) = '55'
+                   THEN right(d, length(d) - 2)
+                   ELSE d END;
+
+  -- The TRUNK PREFIX. '(011) 99888-7777' is how half of Brazil still writes a
+  -- number, and keeping the 0 made it a different key from the E.164 the
+  -- opt-out stores \u2014 a silent MISS, which on a consent check means the message
+  -- goes out. Stripped after the country code, because '055...' exists too.
+  IF length(national) IN (11, 12) AND left(national, 1) = '0' THEN
+    national := right(national, length(national) - 1);
+  END IF;
+
+  -- Restore the ninth digit on a pre-2016 mobile so that the same person
+  -- written both ways resolves to one key.
+  --
+  -- KNOWN AMBIGUITY, not solved here: a ten-digit foreign number stored with
+  -- no country code \u2014 '(917) 555-1234' \u2014 is indistinguishable from a Brazilian
+  -- one and gets repaired into DDD 91. In a Brazilian product a bare national
+  -- number IS Brazilian; storing a US number without its +1 is already lossy.
+  -- The failure needs a real opt-out on that exact DDD-91 number to bite.
+  IF length(national) = 10 AND substr(national, 3, 1) ~ '^[6-9]$' THEN
+    national := left(national, 2) || '9' || right(national, 8);
+  END IF;
+
+  -- Shorter than eight digits is not a phone number; returning it would let a
+  -- truncated string match a real opt-out. Longer than eleven is not one
+  -- either \u2014 it is two numbers, or a number with an extension glued on, and
+  -- \`notifications_phone_keys\` is what takes those apart.
+  IF length(national) < 8 OR length(national) > 11 THEN RETURN NULL; END IF;
+  RETURN national;
+END $$;
+
+-- Every number a free-text field might be carrying.
+--
+-- \`people.phone\` has no format and no normalising trigger. Real rows hold
+-- '(11) 99888-7777 / (11) 3333-4444' and '(11) 99888-7777 ramal 12', and
+-- comparing the whole string to an E.164 opt-out misses both \u2014 the person asked
+-- to stop and the message goes out anyway.
+--
+-- So the left-hand side is a SET. The regex takes runs that could be a number
+-- (digits and the punctuation people put between them) and stops at anything
+-- else \u2014 a slash, the word "ramal" \u2014 which is what separates one number from
+-- the next.
+CREATE OR REPLACE FUNCTION public.notifications_phone_keys(p_phone text)
+RETURNS text[]
+LANGUAGE sql IMMUTABLE
+SET search_path TO ''
+AS $$
+  SELECT coalesce(
+    array_agg(DISTINCT k) FILTER (WHERE k IS NOT NULL),
+    '{}'::text[]
+  )
+  FROM (
+    SELECT public.notifications_phone_key(m[1]) AS k
+      FROM regexp_matches(coalesce(p_phone, ''), '\\+?[0-9][0-9\\s().-]{6,}', 'g') AS m
+  ) s;
+$$;
+
+COMMENT ON FUNCTION public.notifications_phone_keys(text) IS
+  'Every comparable phone key a free-text contact field carries. One field can hold two numbers.';
+
+REVOKE ALL ON FUNCTION public.notifications_phone_keys(text) FROM PUBLIC;
+GRANT EXECUTE ON FUNCTION public.notifications_phone_keys(text) TO service_role;
+
+COMMENT ON FUNCTION public.notifications_phone_key(text) IS
+  'National digits of a phone number, for comparing a free-text people.phone against an E.164 opt-out record.';
+
+REVOKE ALL ON FUNCTION public.notifications_phone_key(text) FROM PUBLIC;
+GRANT EXECUTE ON FUNCTION public.notifications_phone_key(text) TO service_role;
+
+CREATE OR REPLACE FUNCTION public.notifications_resolve_channel(p_tenant_id uuid, p_key text, p_person_id uuid, p_locale text DEFAULT 'pt-BR'::text, p_requested text DEFAULT NULL::text, OUT channel text, OUT blocked_reason text) RETURNS record
+    LANGUAGE plpgsql STABLE SECURITY DEFINER
+    SET search_path TO ''
+    AS $_$
+DECLARE v_pref record; v_default text; v_optout boolean := false; v_phone_keys text[];
+BEGIN
+  -- plugin-conversations' opt-out is absolute and is checked first: it is the
+  -- record of the person telling the business to stop, and no template, purpose
+  -- or preference of ours outranks it.
+  --
+  -- Matched by PHONE, because that is the only thing the opt-out carries. See
+  -- the header of this migration for why the previous person_id comparison
+  -- could never have matched and why it failed quietly.
+  IF to_regclass('public.plg_conversations_optouts') IS NOT NULL THEN
+    BEGIN
+      SELECT public.notifications_phone_keys(pe.phone) INTO v_phone_keys
+        FROM public.people pe
+       WHERE pe.id = p_person_id;
+
+      -- The query runs even when the person has NO phone, on purpose. Guarding
+      -- it on a non-empty key set meant a table whose shape this version does
+      -- not understand was only ever detected for people who happened to have a
+      -- number \u2014 everybody else sailed past the broken check and was sent to.
+      -- An empty array simply matches nothing.
+      --
+      -- \`tenant_id IS NULL\` is load-bearing: \`tyxter-webhook\` writes every
+      -- opt-out with a null tenant, so a tenant-only comparison would match
+      -- none of the records that actually exist.
+      EXECUTE 'SELECT EXISTS (
+                 SELECT 1 FROM public.plg_conversations_optouts o
+                  WHERE (o.tenant_id = $1 OR o.tenant_id IS NULL)
+                    AND public.notifications_phone_key(o.phone_e164) = ANY ($2))'
+        INTO v_optout USING p_tenant_id, coalesce(v_phone_keys, '{}'::text[]);
+    EXCEPTION WHEN OTHERS THEN
+      -- RAISE, do not block.
+      --
+      -- Fail-closed was right; writing a blocked ROW to achieve it was not.
+      -- \`notifications_enqueue\` stores the caller's \`dedupe_key\` on that row and
+      -- short-circuits on it forever after, so one transient read failure
+      -- destroyed that message permanently \u2014 including an invoice-due or an
+      -- order confirmation, whose dedupe keys are per-event and never come
+      -- round again.
+      --
+      -- Raising instead leaves the delivery to \`consume_event_log\`, which
+      -- already retries with backoff and abandons visibly after max_attempts.
+      -- Nothing is sent either way; only one of the two is recoverable.
+      RAISE EXCEPTION 'notifications_resolve_channel: could not read plg_conversations_optouts (%)', SQLERRM
+        USING ERRCODE = '55000';
+    END;
+  END IF;
+
+  IF v_optout THEN
+    channel := NULL; blocked_reason := 'conversations opt-out'; RETURN;
+  END IF;
+
+  IF p_requested IS NOT NULL THEN
+    IF EXISTS (SELECT 1 FROM public.plg_notifications_preferences p
+                WHERE p.tenant_id = p_tenant_id AND p.person_id = p_person_id
+                  AND p.channel = p_requested AND NOT p.opted_in) THEN
+      channel := NULL; blocked_reason := format('recipient opted out of %s', p_requested); RETURN;
+    END IF;
+    channel := p_requested; blocked_reason := NULL; RETURN;
+  END IF;
+
+  SELECT p.channel INTO v_pref
+    FROM public.plg_notifications_preferences p
+    JOIN public.plg_notifications_templates t
+      ON t.tenant_id = p.tenant_id AND t.key = p_key AND t.channel = p.channel
+     AND t.locale = p_locale AND t.is_active
+   WHERE p.tenant_id = p_tenant_id AND p.person_id = p_person_id AND p.opted_in
+   ORDER BY p.priority, p.channel
+   LIMIT 1;
+
+  IF v_pref.channel IS NOT NULL THEN
+    channel := v_pref.channel; blocked_reason := NULL; RETURN;
+  END IF;
+
+  -- No preference is not "no message": the template declares the fallback.
+  SELECT t.channel INTO v_default
+    FROM public.plg_notifications_templates t
+   WHERE t.tenant_id = p_tenant_id AND t.key = p_key AND t.locale = p_locale
+     AND t.is_active AND t.is_default
+   LIMIT 1;
+
+  IF v_default IS NULL THEN
+    SELECT t.channel INTO v_default
+      FROM public.plg_notifications_templates t
+     WHERE t.tenant_id = p_tenant_id AND t.key = p_key AND t.locale = p_locale AND t.is_active
+     ORDER BY t.channel LIMIT 1;
+  END IF;
+
+  IF v_default IS NOT NULL
+     AND EXISTS (SELECT 1 FROM public.plg_notifications_preferences p
+                  WHERE p.tenant_id = p_tenant_id AND p.person_id = p_person_id
+                    AND p.channel = v_default AND NOT p.opted_in) THEN
+    channel := NULL; blocked_reason := format('recipient opted out of %s', v_default); RETURN;
+  END IF;
+
+  channel := v_default;
+  blocked_reason := CASE WHEN v_default IS NULL THEN 'no active template for this key' END;
+END $_$;
+
+-- \u2500\u2500 index \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500
+
+-- The lookup is \`notifications_phone_key(o.phone_e164) = ANY(...)\`, which no
+-- existing index can serve: without this it is a sequential scan of the whole
+-- opt-out table on EVERY enqueue, and because \`tyxter-webhook\` writes every
+-- record with a null tenant, that table is cluster-wide and only grows.
+--
+-- Guarded: plugin-conversations owns the table and a pool may not have it.
+DO $$
+BEGIN
+  IF to_regclass('public.plg_conversations_optouts') IS NOT NULL THEN
+    EXECUTE 'CREATE INDEX IF NOT EXISTS plg_conversations_optouts_phone_key_idx
+               ON public.plg_conversations_optouts (public.notifications_phone_key(phone_e164))';
+  END IF;
+END $$;
+`;
 var MIGRATIONS = [
   { id: "000_baseline", sql: MIGRATION_000_BASELINE },
-  { id: "001_o_historico_diz_por_que_nao_chegou", sql: MIGRATION_001_O_HISTORICO_DIZ_POR_QUE_NAO_CHEGOU }
+  { id: "001_o_historico_diz_por_que_nao_chegou", sql: MIGRATION_001_O_HISTORICO_DIZ_POR_QUE_NAO_CHEGOU },
+  { id: "002_the_opt_out_is_checked_by_phone", sql: MIGRATION_002_THE_OPT_OUT_IS_CHECKED_BY_PHONE }
 ];
 
 // src/data/tables.ts