lekss361
ca1015bd4e
All checks were successful
Deploy Trade-In / test (push) Successful in 4m59s
Deploy Trade-In / build-backend (push) Successful in 1m10s
Deploy Trade-In / deploy (push) Successful in 1m17s
Deploy Trade-In / changes (push) Successful in 14s
Deploy Trade-In / build-frontend (push) Has been skipped
Deploy Trade-In / build-browser (push) Has been skipped
122 lines
11 KiB
PL/PgSQL
122 lines
11 KiB
PL/PgSQL
-- 187_web_support_chat.sql
|
||
-- Web-чат поддержки (сайт МЕРА) поверх УЖЕ существующего Telegram support-моста
|
||
-- (data/sql/186_tg_support.sql, app/services/tgbot/bridge.py). Источник обращения
|
||
-- меняется (сайт вместо Telegram-лички клиента), маршрутизация ответа оператора
|
||
-- (реплай на зеркало в топике супергруппы) остаётся ТОЙ ЖЕ — оператор ничего
|
||
-- нового не учит.
|
||
--
|
||
-- ПОЧЕМУ ОТДЕЛЬНЫЕ ТАБЛИЦЫ, А НЕ "tg_support_* + channel"
|
||
-- (взвешено явно, per code review requirement):
|
||
--
|
||
-- Вариант А (отклонён) — добавить channel text ('telegram'|'web') в
|
||
-- tg_support_users/tg_support_messages:
|
||
-- - tg_support_users.chat_id bigint PRIMARY KEY — это Telegram private
|
||
-- chat id клиента. У веб-пользователя сайта ЕГО НЕТ (клиент никогда не
|
||
-- писал боту в личку) — пришлось бы либо (а) городить синтетический
|
||
-- chat_id для веб-юзера (напр. отрицательный hash от username) — это
|
||
-- вводит ВТОРУЮ систему идентификации внутри одной PK-колонки,
|
||
-- семантика которой документирована как "Telegram chat id" (186:54),
|
||
-- либо (б) делать chat_id NULLABLE и городить ещё одну колонку
|
||
-- username NULLABLE рядом — таблица с двумя взаимоисключающими
|
||
-- identity-схемами и кучей CHECK-ограничений вида
|
||
-- "chat_id XOR username NOT NULL".
|
||
-- - Доставка обратно ТОЖЕ разная: Telegram-путь шлёт copyMessage в личку
|
||
-- клиента, веб-путь просто пишет строку в БД (personal chat не
|
||
-- существует) — код в bridge.py и так ветвится по каналу, общая
|
||
-- таблица не убирает эту ветку, только добавляет NULL-поля.
|
||
-- - Риск регрессии: tg_support_* уже покрыты test_bridge.py (14+
|
||
-- кейсов) и работают в проде (PR #2526) — трогать рабочую, протестированную
|
||
-- схему ради ещё не запущенной фичи повышает blast radius без выгоды.
|
||
--
|
||
-- Вариант Б (выбран) — новые web_support_threads/web_support_messages:
|
||
-- - Идентификатор клиента — username (X-Authenticated-User, сайт закрыт
|
||
-- Caddy basic_auth, публичного доступа нет — см. app/main.py rbac_guard)
|
||
-- — чистый, не smoke-и-зеркала не переиспользующий Telegram identity.
|
||
-- - topic_message_id-маршрутизация (ключевой механизм моста) СОХРАНЕНА
|
||
-- 1-в-1 по конвенции 186: partial UNIQUE на topic_message_id,
|
||
-- заполняется только для direction='in', NULL для direction='out'.
|
||
-- - bridge.py меняется МИНИМАЛЬНО: _handle_group_reply получает одну
|
||
-- дополнительную ветку (резолвит tg-путь И web-путь, потом
|
||
-- existing orphan-warning) — существующий Telegram-путь не трогается.
|
||
--
|
||
-- ⚠️ CROSS-TABLE КОЛЛИЗИЯ topic_message_id (review M1, зафиксировано ДО
|
||
-- первого прод-использования, пока обе таблицы пусты):
|
||
-- Инвариант "topic_message_id уникален между tg_support_messages и
|
||
-- web_support_messages" на самом деле звучит так: "уникален, ПОКА
|
||
-- TELEGRAM_SUPPORT_CHAT_ID не менялся". Это OPS-инвариант, а НЕ DB-инвариант —
|
||
-- ничем не гарантирован. Смена/пересоздание support-группы обнуляет счётчик
|
||
-- Telegram message_id в новом чате; когда он дорастёт до диапазона,
|
||
-- использованного старым чатом, — number, ранее занятый ОДНОЙ таблицей,
|
||
-- может совпасть с числом, занятым ДРУГОЙ. Внутри одной таблицы partial
|
||
-- UNIQUE превращает такую коллизию в громкий отказ INSERT — это ок. МЕЖДУ
|
||
-- таблицами constraint'а нет: без доп. скоупинга бот молча доставил бы ответ
|
||
-- оператора НЕ ТОМУ клиенту (152-ФЗ-инцидент, происходящий тихо).
|
||
-- Фикс: колонка `support_chat_id` на web_support_messages (симметричная
|
||
-- колонка для УЖЕ применённой tg_support_messages — отдельная миграция
|
||
-- 188_tg_support_chat_id_scope.sql, эту таблицу нельзя трогать здесь, она
|
||
-- уже применена/задеплоена как часть 186). Резолв (bridge.py) матчит ПАРУ
|
||
-- (support_chat_id, topic_message_id), а не topic_message_id в одиночку;
|
||
-- NULL (легаси-строки без этой колонки) — лениентный wildcard, т.к. на тот
|
||
-- момент действовал ровно один чат.
|
||
--
|
||
-- ЧТО:
|
||
-- - web_support_threads — один тред на username (сайт = 1 логин = 1 линия
|
||
-- переписки с поддержкой, без под-тредов).
|
||
-- - web_support_messages — лог переписки, direction='in' (от юзера) |
|
||
-- 'out' (ответ оператора, реплай из bridge.py).
|
||
--
|
||
-- 152-ФЗ:
|
||
-- Переписка (text_body) — ПДн (может содержать любые данные, которые юзер
|
||
-- решит написать). ON DELETE CASCADE от web_support_threads делает erasure
|
||
-- ОДНОЙ операцией (DELETE FROM web_support_threads WHERE username = :u) ДЛЯ
|
||
-- КОПИИ В ЭТОЙ БД. Копия того же текста уже ушла в Telegram-топик (sendMessage
|
||
-- зеркало) и живёт ТАМ вне зоны действия этого DELETE — реальное "право на
|
||
-- забвение" по всей цепочке требует ОТДЕЛЬНОЙ процедуры (удаление сообщений в
|
||
-- Telegram-супергруппе через Bot API deleteMessage, вне scope этой миграции).
|
||
-- Не ссылаться на этот комментарий как на доказательство полного erasure.
|
||
--
|
||
-- IDEMPOTENCY: CREATE TABLE/INDEX IF NOT EXISTS — безопасный re-run.
|
||
-- Зависимости: нет (новые standalone таблицы, никакие существующие
|
||
-- tg_support_*/иные таблицы не трогаются — см. 188 для ALTER на tg_support_messages).
|
||
|
||
BEGIN;
|
||
|
||
CREATE TABLE IF NOT EXISTS web_support_threads (
|
||
id bigserial PRIMARY KEY,
|
||
username text NOT NULL UNIQUE,
|
||
created_at timestamptz NOT NULL DEFAULT now(),
|
||
last_seen_at timestamptz NOT NULL DEFAULT now(),
|
||
last_read_at timestamptz NOT NULL DEFAULT now()
|
||
);
|
||
|
||
COMMENT ON TABLE web_support_threads IS '152-ФЗ: одна строка на username (сайт МЕРА, X-Authenticated-User) — единый тред переписки с поддержкой через веб-чат. Удаление клиента — DELETE FROM web_support_threads WHERE username=...; ON DELETE CASCADE в web_support_messages подчищает переписку одной операцией.';
|
||
COMMENT ON COLUMN web_support_threads.username IS 'X-Authenticated-User (Caddy basic_auth) — сайт закрыт, анонимов нет, см. app/main.py rbac_guard.';
|
||
COMMENT ON COLUMN web_support_threads.last_seen_at IS 'Обновляется при отправке юзером нового сообщения (send-активность, НЕ на чтение истории).';
|
||
COMMENT ON COLUMN web_support_threads.last_read_at IS 'Отметка "прочитано до" (POST /api/v1/trade-in/support/read) — используется для счётчика непрочитанного (GET /support/unread).';
|
||
|
||
CREATE TABLE IF NOT EXISTS web_support_messages (
|
||
id bigserial PRIMARY KEY,
|
||
thread_id bigint NOT NULL REFERENCES web_support_threads (id) ON DELETE CASCADE,
|
||
direction text NOT NULL CHECK (direction IN ('in', 'out')),
|
||
text_body text NOT NULL CHECK (char_length(btrim(text_body)) > 0),
|
||
topic_message_id bigint,
|
||
support_chat_id bigint,
|
||
operator_tg_id bigint,
|
||
created_at timestamptz NOT NULL DEFAULT now()
|
||
);
|
||
|
||
COMMENT ON TABLE web_support_messages IS '152-ФЗ: полный лог веб-чата поддержки (ПДн — содержимое сообщений; удаление подчищает КОПИЮ В ЭТОЙ БД, не Telegram-топик — см. блок 152-ФЗ выше). Каскадно удаляется вместе с web_support_threads по username.';
|
||
COMMENT ON COLUMN web_support_messages.direction IS '''in'' — сообщение от пользователя сайта; ''out'' — ответ оператора (доставлен через реплай в Telegram-топике, см. bridge.py _handle_group_reply).';
|
||
COMMENT ON COLUMN web_support_messages.text_body IS 'Текст сообщения. Веб-чат — текстовый MVP, медиа не поддерживается (в отличие от tg_support_messages.kind).';
|
||
COMMENT ON COLUMN web_support_messages.topic_message_id IS 'id зеркала (sendMessage) в support-топике — ключ маршрутизации ответа, только для direction=''in''. NULL для ''out'' (конвенция 186: маршрутизирующий ключ живёт исключительно на inbound-записи).';
|
||
COMMENT ON COLUMN web_support_messages.support_chat_id IS 'TELEGRAM_SUPPORT_CHAT_ID в момент отправки — скоупит резолв topic_message_id к ТЕКУЩЕЙ support-группе (review M1: без этого поля ротация группы даёт тихую cross-table коллизию, см. блок выше). NULL — лениентный wildcard для строк без этого поля.';
|
||
COMMENT ON COLUMN web_support_messages.operator_tg_id IS 'Telegram user id оператора, ответившего в топике; заполняется только для direction=''out''.';
|
||
|
||
CREATE UNIQUE INDEX IF NOT EXISTS web_support_messages_topic_message_id_uq
|
||
ON web_support_messages (topic_message_id)
|
||
WHERE topic_message_id IS NOT NULL;
|
||
|
||
CREATE INDEX IF NOT EXISTS web_support_messages_thread_id_created_at_idx
|
||
ON web_support_messages (thread_id, created_at DESC);
|
||
|
||
COMMIT;
|