Files
portal/app/tests/Feature/ClientSms
Дмитрий 9f3ac393cb feat(смс-клиент): итог рассылки — доставлено, не доставлено, ещё в пути
Строка листа 5.3. До этого экран знал только «отправлено 900» — то есть сколько
сообщений мы отдали оператору. Дошли ли они до людей, портал не знал вовсе, а платит
клиент именно за то, чтобы дошли.

Новый счётчик ClientSmsDeliveryCounter — единственный дом этого счёта, как SmsQuietHours
для окна 10–20 и ClientSmsVolumeCounter для месячного объёма. Итог отдаётся и в карточке
рассылки, и в списке рассылок (одним запросом на все пятьдесят, а не по одному).

«Ещё в пути» — это и явное «везу» от оператора, и те, кого мы ещё не спрашивали: для
человека это одно состояние «пока не знаем» (В-214). Пробные сообщения песочницы в счёт
не идут — за них не платят.

Счётчик ставит пометку клиента САМ (В-221): у журнала сообщений изоляция принудительная,
и запрос без пометки под рабочей ролью возвращает ноль строк молча — экран написал бы
«доставлено 0». На стенде эта дыра невидима в принципе (тесты идут под postgres), поэтому
проверена живым прогоном под ролью crm_app_user: со счётчиком 3/1/1/2, тот же запрос без
пометки — ноль.

Тесты: 5 новых, каждый проверен вырезом. Тест списка рассылок пришлось починить (В-223):
со списком из ОДНОЙ рассылки он не отличал «итог своей» от «итог первой попавшейся» и не
краснел на такой подмене — теперь в нём две рассылки с разными числами.

Отдельная запись про приборы (В-222): мой собственный скрипт вырезов соврал — падение
стенда он засчитывал как зелёный тест, а один вырез я забыл вернуть. Обе поломки чинены
в скрипте, а не обойдены.
2026-07-31 08:52:06 +03:00
..