На 390px таблицы «Не поднимают трубку» и «Открыли ссылку, но не подтвердили»
уезжали вправо (статус и телефон не видны без прокрутки). На мобильном они
раскладываются списком: телефон и число попыток в строку, город/тип/статус и
дата — ниже мелким. В таблице попыток процент ответов уходит во вторую строку,
чтобы колонка «Не взяли» влезла. Тест на мобильную раскладку (8 проверок). SW v125.
Владелец: «нужно видеть, как всё происходит: push отправили — реакции не было, потом SMS,
потом звонок; с какого раза человек ответил на звонок, кто вообще не поднимает трубку».
Один RPC admin_comms_funnel(p_days, p_date_from, p_date_to) — период считается как у
admin_automation_economics (30 = группы, созданные за 30 дней; 0 = всё время) — отдаёт:
этапы цепочки по когорте (группы → push → первое SMS → открыли ссылку → позвонили →
взяли трубку → согласовано → в ручную → выдано), разбивку звонков по попыткам
(всего/взяли/согласовали/не взяли + % ответов), каналы подтверждения (робот / менеджер /
ссылка), список «не поднимают трубку» и «открыли ссылку, но не подтвердили», и «silent» —
кого не достали ни ссылкой, ни звонком.
Блок CommsFunnelBlock на «Аналитике» под KPI-карточками, те же табы периода, mobile-first,
время в МСК. За 30 дней: 396 групп, первое SMS 340, открыли ссылку 1, звонили 26,
взяли трубку 14, согласовано 128, в ручную 22, выдано 357; 265 (66.9%) не достали никак.
С попыток: 1-я — 42 ответа из 64, 2-я — 2 из 6, 3-я — 4 из 4.
Тест: src/components/admin/analytics/CommsFunnelBlock.test.jsx (7 проверок, фикстура по
реальному ответу RPC). SW: v123 -> v124.
В узкой колонке «Вторая половина дня» переносилась посреди фразы («Вторая /
половина дня»). Дата — первой строкой, половина дня — второй, мелким. SW: v123.
Владелец: «в таблице всех доставок и самовывоза, если согласована доставка, дата
и время указаны, а если самовывоз — нет; нужно и самовывоз выводить».
Причина: колонка «Дата» (LogisticsReadinessBoard) читала только delivery_date/
delivery_time, а у самовывоза дата и половина дня лежат в pickup_date/
pickup_time_slot — поэтому строка самовывоза показывала «—», хотя слот согласован.
Тот же пропуск был в фильтре по периоду и группировке по датам: getDeliveryDate()
смотрела только на delivery_date, и при выбранном периоде заказы самовывоза
пропадали из реестра (падали в дату заказа).
Введены общие хелперы в orderGroupViews: isPickupGroup, getGroupSlotDate,
getGroupSlotTime (камелкеис и snake_case). Реестр показывает дату и время слота
по типу заказа, сортировка — по этой же показанной дате, фильтр по периоду и
группировка — тоже по ней. Подпись колонки «Доставка» → «Дата» (в колонке теперь
и дата выдачи).
Попутно поправлено устаревшее ожидание в тесте (getOrderGroupDisplayStatusLabel
для черновика ждало «draft», подпись локализована в «Черновик») — тест падал и до
этой правки.
SW: v121 -> v122.
Владелец: «в субботу звонки не должны происходить, всё это настраивается из
админки». В панели «Автодозвон» в блоке «Окно звонков» были только часы, а дни
(work_days) править из админки было нечем — их приходилось менять в БД, хотя
планировщик именно по ним и решает, звонить ли сегодня.
Добавлены таблетки дней Пн–Вс тем же механизмом и в том же виде, что в панели
SMS-кампаний: пустой набор не подменяется дефолтом (снял все дни — значит
звонков нет, и в панели это видно). Подсказка в панели теперь честно описывает
поведение: вне окна робот не звонит вообще, попытка уходит на ближайшее
рабочее утро.
Харнесс check_autocall_window.py считает ожидания ИЗ НАСТРОЕК (часы + дни),
поэтому проверка не устаревает при смене графика.
SW: v120 -> v121.
Харнесс прогоняет планировщик с фейковым временем и подменённым push_call_file:
19:58 и 21:03 МСК (инцидент) — звонков нет, 09:00/10:00/18:59 — звонок есть,
воскресенье — нет, суббота — есть. Работает и для файла-кандидата до установки.
Владелец: «звонить вне окна разрешённого нельзя». Окно (часы и дни из панели
«Автодозвон») проверялось только для ручной очереди «Позвонить сейчас», а
автоматическая кампания его игнорировала: 28.09 робот позвонил клиенту в 19:58
и 21:03 МСК (в логе тик сам писал «Outside work hours», но тут же «Found 1
groups» → «Pushed call file»), после чего заказ ушёл в ручную работу.
Теперь перед выборкой кандидатов стоит та же проверка is_work_time(): вне окна
авто-обзвон не запускается, повтор, чей интервал истёк вечером, ждёт ближайшего
рабочего утра. Проверка: /tmp-check_window.py — 7 случаев (вне окна 19:58 и
21:03, внутри 09:00/10:00/18:59, воскресенье, суббота), все PASS; в логе новая
строка «Outside work hours (09:00-19:00 МСК (...)), auto calls skipped».
В блоке «История действий по заказу» автодозвон не был виден в цепочке шагов —
там были только «Добавлен», «SMS», «Согласовано» и далее, хотя робот звонит по
этим же заказам. Теперь шаг «Звонок» идёт сразу после SMS в обеих цепочках
(доставка и самовывоз) и имеет собственное состояние: ✓ пройден, если робот
согласовал слот; янтарный — если звонили без результата; серый — если звонков
не было. Шаг не считается пройденным только потому, что заказ уже согласован
(согласовать могли по ссылке из SMS, без звонка). Подсказка при наведении —
последний исход и число звонков.
SW: v119 -> v120.
В тестовом режиме робот звонит на тестовый номер, но нажатия уходили в заказ
клиента: заказ получал статус «согласовано роботом», дату, комментарий и
счётчик попытки — хотя клиенту не звонили. Теперь при was_test_mode:
- строка журнала пишется без привязки к заказу (order_group_id = null),
- заказ не обновляется вообще (ранний выход до всех update).
Симптом на проде 28.09: заказ ТП-010796 (9788324113) получил
«Согласовано роботом: сегодня, вторая половина дня» после тестового звонка.
- getInvitationReferenceLabel/getDeliveryNumberDigits вынесены в отдельный тест-файл
(без импорта supabaseClient) — проверяются номер доставки и «Доставка …»
- supabaseClient: lock берём как «no-lock», если navigator.locks.request нет
(jsdom) — иначе весь тест-файл падал на импорте и тесты страницы не запускались
Клиентская страница согласования:
- приглашение теперь отдаёт deliveryType и pickupCode (public view) — до этого
страница не знала, что заказ самовывозный, и говорила «Доставка заказа /
Согласование доставки» даже для самовывоза; в шапке и hero-тексте выбор по типу
- в блоке с кодом: «Ваш номер доставки 010796» + «Ваш код выдачи 7598»
(номер берём из состава заказа, «ТП\-010796» → «010796»)
- ссылка на заказ теперь «Доставка ТП-010796» вместо «Счет ТП\-010796»,
экранированный дефис из обмена с 1С больше не показывается
SMS: в шаблоны добавились переменные {order}/{номер}/{номер_доставки} (номер
доставки) и {code}/{код}/{код_выдачи} (код выдачи) — работают и в шаблоне
кампании, и в тексте профиля города. Дефолтные тексты самовывоза (и значения в
БД, см. supabase/sms_pickup_code_placeholders.sql) теперь содержат номер и код;
в админке у полей появилась памятка по переменным и предпросмотр с подстановкой.
service-worker v118 → v119
- supabase/log_order_group_change.sql, supabase/order_history_rls.sql: триггер
логирования изменений order_groups и его RLS существовали только на сервере
(в БД работают с 2026-07-29), в git исходников не было — восстановить было нечем
- scripts/__pycache__/*.pyc и DriverDeliveryPlanner.jsx.bak сняты с отслеживания
(артефакты и бэкап, в .gitignore уже были __pycache__/ и *.bak — добавлен *.bak-*)
Раньше текст был зашит в кампании и всегда говорил про доставку; настраиваемый
в админке sms_text_template не читался скриптами вообще. Сначала выяснилось,
что всем 909 pickup-группам уходило «Согласуйте дату доставки по ссылке».
- sms_campaign_settings.sms_text_template_pickup (новая колонка) + значения
sms_text_template = «…дату доставки…», pickup = «…дату самовывоза…»
(supabase/sms_text_templates_pickup.sql = миграция с фактическими текстами)
- sms_first_campaign / sms_second_campaign / sms_paid_storage_campaign:
build_sms_text(group, settings) — шаблон выбирается по og.delivery_type,
{link} подставляется ссылкой; приоритет профиль города (режим «Уведомление»)
→ шаблон кампании → дефолт скрипта
- вторая SMS и платное хранение тоже получили pickup-вариант (кампании были
выключены, поэтому в текстах жил только «доставка»)
- SmsCampaignPanel: два поля ввода (📦 Доставка / 🏪 Самовывоз) + длины и
предпросмотр с подставленной ссылкой + пояснение приоритета
- service-worker v117 (обязательный бамп при деплое фронта)
Решение владельца: у самовывоза дата живёт в pickup_date + pickup_time_slot,
delivery_date/delivery_time робот не трогает (раньше дублировал в оба поля,
и дата самовывоза всплывала в полях доставки). Маркер «согласовано роботом»
общий — delivery_date_source='autocall': по нему работают карточка, фильтры и
SQL-статус autocall_status(og); отдельного pickup_date_source в схеме нет.
Проверено на боевой функции временными группами с метками в датах:
самовывоз — pickup_date обновился, delivery_date остался нетронутым;
доставка — delivery_date обновился, pickup_date нетронут. Временные группы удалены.
Исторический дубль (единственный: ТП-010747) очищен — дата осталась в pickup_date.
Проверка цепочки «варианты в меню → цифра → дата в заказе» нашла два дефекта:
1. edge-функция: если дата в call-файл не попала (старый файл/сбой), дата считалась
как «сегодня + цифра − 1» для ОБОИХ типов. Для доставки это сдвигало день на
сутки назад: абонент нажимает «день 1» (робот говорит «завтра»), а в заказ
уезжает сегодня. Теперь fallback повторяет ОЗВУЧЕННУЮ семантику: самовывоз
день 1 = сегодня (сегодня/завтра/послезавтра), доставка день 1 = завтра,
день 2 = послезавтра. Проверено живыми POST на функцию (5 случаев, включая
приоритет chosen_date) — временная группа создана и удалена.
2. планировщик: при пустом «Графике работы» окна подменяют пустой список
дефолтом Пн–Пт, то есть робот предлагал бы дни, когда компания не работает.
Теперь при пустом графике звонок пропускается с понятным предупреждением.
Цепочка «варианты → цифра → дата» проверена на живых окнах: пятница 17:41 → доставка
пн/вт, самовывоз после отсечки 15:30 — только пн (2 варианта), при готовности сегодня
до 15:30 — 3 варианта (пт/пн/вт), цифры 1/2/3 → PICKUP_DAY1/2/3 и DELIVERY_DAY1/2
уходят в диалог и возвращаются как chosen_date.
Канал call-файла строится из настройки autocall_trunk (sms_campaign_settings):
'gsm' — PJSIP/1<номер с 8>@goip5 (линия 1 модуля), 'mmedia' — прежний SIP-транк.
По умолчанию gsm.
У модуля одна SIM → один одновременный звонок: перед постановкой в спул сверяем
занятость каналов транка на АТС и ставим не больше, чем есть свободных линий.
Не успевшие звонки просто ждут следующего тика таймера — иначе они падали бы
«занято» и уезжали в «не ответил». То же для ручных звонков из очереди.
Цифра дня у робота (dtmf_day) — это не «завтра», а первый рабочий день окна:
звонок в пятницу предлагает понедельник, а суббота выходная. Карточка писала
«завтра, вторая половина дня» при согласованном 28.09 — менеджер видел день,
которого в окне нет.
Слот собирает общая функция components/orders/autocallSlot.js: дата из строки
лога (chosen_date), для старых строк — дата заказа, если слот согласовал этот
звонок. Если даты нет — показываем только половину дня, ничего не выдумывая.
Подключено в карточке заказа, вкладке «Автодозвон» и панели тест-звонка.
Есть юнит-тесты (5 кейсов).
Причина «кучи ошибок 107»: номер попытки читался из строки лога
(attempts = item.get("attempts", 1)), а каждая повторная отправка вставляла
НОВУЮ строку с attempts=1. Условие attempts < max_attempts выполнялось всегда,
поэтому группа уходила в повтор каждые 5 минут бесконечно: заказ ТП-010543
(9780187307) — 461 отправка за 3,5 суток, ни одна не доставлена, в ручную
работу заказ не ушёл.
- номер попытки считается по группе (count строк кампании) и пишется в строку
и в order_groups.sms_attempts;
- в выборке на отправку жёсткий лимит попыток — повтор невозможен даже при
сбое статуса;
- попытки исчерпаны → manual_required («нужен менеджер»), а не send_failed;
- новый шаг 4: группа с исчерпанными попытками, застрявшая в link_ready,
сама уходит в manual_required (самолечение);
- то же исправление во второй кампании (second_sms) — там тот же баг.
Hermes
Hermes
hermes