Дополнение к PR #548 при мерже. Код менять не пришлось — добавлены три теста.
Решение «это 409» автор вынес в утилиту и покрыл хорошо, а вот сама привязка
onError к мутациям осталась непокрытой — при том, что её отсутствие и есть
исходный баг: форма молчала, человек жал «Отправить» повторно. Проверил
мутациями: снятие onError у createMutation, снятие onError у replyMutation и
удаление обновления списка тикетов в ветке 409 набор не роняли.
Окружения для рендера компонентов в репозитории нет (vitest настроен на node,
без jsdom), поэтому закрепил структурно, по исходнику — приём тот же, что уже
используется в бот-репозитории. Крудовато, но ловит ровно ту регрессию, ради
которой PR и написан.
Остальное проверено, правок не потребовалось. Несущее допущение верно: 409 в
app/cabinet/routes/tickets.py встречается ровно один раз и именно про открытый
тикет, так что матч по статусу вместо текста detail — правильный выбор (текст
приходит только по-английски, а кабинет и бот версионируются раздельно).
Переименование rateLimitError → formError сквозное, хвостов не осталось; формы
create и reply взаимоисключающие, состояние сбрасывается на всех переходах.
Ключи support.errors.* есть во всех четырёх локалях. Шесть предупреждений biome
в Support.tsx — предсуществующие, столько же на чистом dev.
`POST /cabinet/tickets` отвечает 409 «You already have an open ticket»,
если у пользователя уже есть незакрытый тикет, но `createMutation` не имела
`onError` — форма молча оставалась на месте. Со стороны это выглядело как
«кнопка Отправить не работает»: пользователь жал её повторно и уходил в
поддержку с вопросом, почему обращение не создаётся. Тем же молчанием
отвечал и ответ в тикет (403 при блокировке в поддержке, 400 на закрытом
тикете).
Обе мутации теперь пишут текст ошибки в состояние формы — тот же блок,
в котором уже показывался клиентский rate-limit (`rateLimitError`
переименован в `formError`, состояние по смыслу общее). Для 409 показываем
локализованную подсказку и обновляем список тикетов: открытый тикет мог
появиться в другой сессии (бот, второе устройство), и после инвалидации
пользователю есть куда перейти. Остальные коды отдают `detail` бэка через
`getApiErrorMessage` с локализованным фолбэком.
409 ловим по статусу, а не по тексту `detail`: он приходит только
по-английски, а кабинет и бот версионируются раздельно.
Дополнения к PR #544 при мерже.
Плитка на главной берёт число подключённых устройств из запроса ['devices'],
а он выключен ровно там, где плитка живёт: `enabled: !!subscription &&
!isMultiTariff`, тогда как блок с плиткой рендерится в мультитарифной ветке,
где `subscription` всегда null (свой запрос отключён по !isMultiTariff).
То есть счётчик показывал бы «0 из N» всегда, лимит устройств не срабатывал бы
никогда, а точки-индикаторы стояли бы пустыми — при том, что счётчик и есть
смысл плитки.
Добавлен запрос по конкретной подписке: getDevices принимает subscription_id,
ключ ['devices', id] — тот же, что на странице подписки, поэтому кэш общий и
лишнего похода в сеть при переходе туда не будет. Заодно вынес выбор
единственной подписки в переменную, чтобы условие показа и данные плитки не
разъезжались.
Отдельно поправлен потерянный пробел в className: `duration-300${...}` склеивал
класс в `duration-300cursor-not-allowed`, из-за чего оформление заблокированной
плитки не применялось. Баг приехал вместе с переносом из SubscriptionCardActive
(там он с самого начала), но раз компонент всё равно выделяется — чиню здесь.
Дополнения к PR #543 при мерже.
С появлением трафика тип balance_and_days перестал означать «есть и баланс, и
дни»: теперь он стоит у любого набора с трафиком, в том числе с нулевым
балансом и нулём дней. Две поверхности этого не учитывали.
Форма редактирования поднимала галочки «Баланс» и «Дни» по ТИПУ. Код с одним
трафиком открывался с двумя чужими галочками на нулях, валидация требовала
«больше 0», и Сохранить не работало — админ не мог поправить даже число
активаций, ничего не меняя по сути. Хуже того, подсказка прямо предлагает
вписать сумму: сделав это, админ молча превращал код на 50 ГБ в код на 50 ГБ
плюс 100 рублей. Галочки теперь выводятся по значениям — ровно так, как сам
автор уже сделал для трафика строкой ниже.
Список промокодов печатал составляющие тоже по типу, поэтому код с одним
трафиком показывался как «+0 ₽ +0 дн.» и ни слова про гигабайты: админ при
разборе списка видел код, который якобы не даёт ничего. Теперь каждая
составляющая показывается по своему значению, и добавлена строка трафика —
ключ form.gb автор уже завёл во всех четырёх локалях.
Дробный ввод не трогал: поведение общее с полями баланса и дней и от этого PR
не зависит.
Дополнение к PR #542 при мерже.
Обработчик глушил ошибку целиком и показывал общее «Ошибка». Между тем сервер
отвечает ровно теми словами, которые админу и нужны: открытый временный доступ
(409, «сначала заверши или восстанови grace»), активная платная без force (409),
подписки нет (404). Первый случай автор сам описал в PR как штатный сценарий —
и именно он выглядел как сломанная кнопка. Прокинул getApiErrorMessage, он для
этого в репозитории и заведён и уже используется в восьми других местах.
Логику force не трогал: она совпадает с сервером. Сериализуемое is_active
собирается в _build_subscription_info как `status == active AND end_date > now`,
то есть в точности серверное свойство Subscription.is_active, по которому и
стоит защита. Разъехаться значения могут только в безопасную сторону: подписка
успела истечь между загрузкой страницы и нажатием — тогда защиты нет и на
сервере.
Дополнения к PR #539 при мерже.
Кнопка «Назад к входу через виджет» оставляла пустое место. Пока открыт
deep-link-экран, контейнер виджета размонтирован ранним return'ом, а эффект,
который вставляет скрипт Telegram, от этого не перезапускается: его
зависимости не меняются. Единственная зависимость, способная дрогнуть, —
handleScriptFailed через scriptLoaded, но на legacy-пути scriptLoaded не
выставляется никогда (только в OIDC-ветке). Так что при возврате контейнер
монтировался обратно уже пустым, и войти через виджет было нельзя до
перезагрузки страницы. Добавлен showDeepLinkUI в зависимости и ранний выход:
на входе в deep-link отрабатывает cleanup, на выходе скрипт вставляется заново.
Локали были только en и ru, а в кабинете их четыре. fallbackLng — 'ru',
поэтому персидские и китайские пользователи увидели бы русский текст на самом
первом экране. Именно этот класс регрессии описан в шапке locales.test.ts, и
поймать его тест не может: он сравнивает только en и ru. Добавлены fa и zh;
в zh термин «виджет» приведён к тому же 小部件, что уже используется в
telegramWidgetBlocked.
Дополнения к PR #534 при мерже.
Юнион sort_by в adminUsers.ts не знал про subscription_end_date. Ошибки
компиляции нет только потому, что вызывающий код собирает params как
Record<string, unknown> и приводит его каст-выражением, то есть юнион там
вообще не проверяется. Но это единственная запись о том, какие значения
принимает эндпоинт, и она разъехалась с реальностью.
Китайская строка «按到期» ставит после 按 глагол, тогда как все соседние
пункты — 按日期, 按余额, 按活跃度, 按消费 — существительные. Сам словарь
кабинета для этого поля использует 到期时间 (subscription.expiresAt,
admin.users.detail.expiresAt, promo.expiresIn), поэтому привёл к той же форме.
Русскую строку не трогал: «по истечению» здесь дательный падеж критерия, как
у соседей («по дате», «по балансу»), а не предложный «по истечении» из
временного оборота.
Подписку может выдать бонус рекламной кампании — она создаётся
автоматически, и человек попадает на главную с уже готовым доступом.
Плитка подключения жила только в карточке подписки на отдельной
странице, так что на главной ему нечем было воспользоваться: подписка
есть, а как подключить устройство — не видно.
Плитка вынесена из SubscriptionCardActive в отдельный компонент и
переиспользована обоими экранами, второй копии разметки не появилось.
На главной показывается, пока подписка одна: при нескольких выбор
устройства неоднозначен, и уместнее уходить в конкретную подписку.
Набор собирался из баланса, дней и промогруппы. Трафик добавляется
четвёртой галочкой: подписка у пользователя уже есть, и гигабайты
начисляются к ней без смены тарифа.
Включённый трафик переводит код в тип «набор бонусов» — на бэкенде
трафик живёт только там. Валидация требует положительный объём, как у
суммы и дней; при редактировании галочка поднимается сама, если у кода
уже задан трафик.
В мультитарифном режиме у пользователя несколько подписок, и убрать
лишнюю — например, отработавший триал — можно было только через экран
«Массовые действия». Во вкладке «Подписка» карточки подписки видны и
открываются, но удалить выбранную нечем.
Кнопка живёт в детальном виде подписки и требует подтверждения тем же
inline-механизмом, что и отмена автоплатежа; ключ подтверждения включает
id подписки, чтобы взведённое согласие не пережило переключение на
соседнюю. Активная платная подписка на сервере защищена от случайного
удаления, поэтому для неё запрос идёт с явным force — намерение админ
уже подтвердил.
- Drop the passive '@bot_username' link (opens the bot chat with no
auth purpose) for the common case — it's now redundant with the new
'Login via bot' button, which offers the same open-bot action plus
QR and actual authentication.
- Keep the referral deep link (bot start=<referral_code>) only when a
referralCode prop is present — that's a distinct registration flow
for not-yet-registered users, not a login method.
- Add an 'or' divider between the widget and the manual deep-link
button so the two remaining options read as equal alternatives
rather than a stack of similar-looking Telegram links.
- Shorten the deep-link button label to 'Login via bot' — the
no-phone-number framing is already implied and shown once the flow
starts.
No changes to the OIDC/widget button logic itself.
Currently the deep-link auth flow (t.me/{bot}?start=webauth_{token}) is
only triggered automatically as a fallback when the Telegram widget
script (oauth.telegram.org or telegram.org/js/telegram-widget.js) fails
to load. Users on unaffected networks have no way to choose this login
method even when they'd prefer confirming in the bot over typing a
phone number into the widget popup.
This adds a small 'Login via bot' link next to the existing widget,
reusing the exact same startDeepLinkAuth/poll logic already used by
the automatic fallback. No changes to the fallback behavior itself.
Remnawave 3.0.0 удалил `uuid` из модели пользователя — панельный аккаунт
адресуется числовым `id`, и бот переименовал соответствующие поля своего
API. Без этих правок вкладка Sync показывала бы «не привязан» у ВСЕХ
пользователей: оба операнда стали бы undefined, причём без ошибки TS —
интерфейсы продолжали бы декларировать несуществующие поля.
Типы: `UserDetailResponse.remnawave_uuid` → `remnawave_id: number | null`,
`PanelSyncStatusResponse.remnawave_uuid` → `remnawave_id`,
`SyncToPanelResponse.panel_uuid` → `panel_user_id`,
`PanelUserInfo.uuid` → `id: number` (бэкенд отдаёт его обязательным).
В SyncTab используется `??`, а не `||`: идентификатор числовой, и `0`
нужно отличать от отсутствия значения. Ярлык — «Remnawave ID».
Локаль: ключ настройки бота переименован в TRAFFIC_EXCLUDED_USER_IDS,
подпись обновлена — значения теперь числовые id, а не UUID.
Дерево разделов настроек — захардкоженный список категорий, а на бэкенде категория
выводится из имени ключа. Любая настройка, создавшая новую категорию, просто
исчезала из админки: настройки были в API, но ни один раздел их не показывал.
Так пропали 33 категории из 102, в том числе:
- CABINET целиком (13 настроек, включая CABINET_ENABLED, CABINET_URL,
CABINET_REQUIRE_LEGAL_CONSENT и CABINET_LEGAL_CONSENT_PRECHECKED);
- INFO_PAGES — режимы показа оферты, политики, правил и FAQ;
- MENU — кнопка меню Telegram с открытием кабинета.
Эти три разложены по дереву явно. Остальное собирает новый пункт «Прочие
настройки» — по образцу админки бота, где такой раздел уже есть. Это и есть
главная часть фикса: теперь новая категория на бэкенде не приводит к молчаливому
исчезновению настроек, максимум — к неудачному разделу.
Локали ru/en/zh/fa, +5 тестов на само дерево.
Новый пользователь попадал в кабинет молча — никаких документов ему не показывали.
Теперь при создании аккаунта он подтверждает, что ознакомился с офертой и политикой.
Набор документов и сам факт включения гейта приходят с бэка
(GET /cabinet/info/legal-consent): там же учитывается, заполнены ли документы и
видны ли они в вебе. Фронт знает только ключи и адреса публичных страниц /offer
и /privacy — тех же, что уже линкует футер логина.
Два пути входа устроены по-разному, поэтому и UI разный:
- регистрация по email — чекбоксы прямо в форме, кнопка заблокирована до галочек;
- Telegram-вход происходит сам собой, спрашивать заранее не у чего. Поэтому ловим
428 от бэка и показываем отдельный экран согласия, а замыкание помнит, какой
именно вход повторить после простановки галочек. Тот же приём страхует и
email-форму: конфиг мог протухнуть, если админ включил гейт между загрузкой
страницы и отправкой.
Неизвестный ключ документа всё равно рисуем (без ссылки): бэк его требует, и молча
спрятанный чекбокс превратился бы в «кнопка не работает и непонятно почему».
Локали ru/en/zh/fa.
Автоматическое ревью справедливо отметило загрузку html5-qrcode с CDN без
проверки целостности: подмена файла на стороне CDN исполнилась бы в кабинете
с полными правами страницы (доступ к сессии, initData Telegram).
Скрипт подключается с integrity (sha384 сверен по фактическому файлу
html5-qrcode@2.3.8), crossorigin=anonymous и referrerPolicy=no-referrer. При
несовпадении хеша браузер откажется исполнять скрипт, и сканер деградирует в
«камера недоступна» вместо запуска чужого кода.
Заодно закрыт тот же изъян в исходном месте, откуда пришёл паттерн:
TvQuickConnect грузил тот же файл с jsdelivr вообще без проверки. Он
переведён на общий хелпер (файлы на unpkg и jsdelivr побайтово идентичны —
сверил), дублирующийся загрузчик и интерфейс удалены.
Виджеты telegram.org намеренно оставлены без SRI: это самообновляемые
эндпоинты Telegram, фиксация хеша сломала бы логин при их обновлении.
Получателю раньше оставалось только скопировать ссылку или код руками.
- QR на экране готового подарка: кодируется bot-ссылка (активация в боте —
основной путь), при отсутствии username бота — ссылка кабинета. Использован
уже имеющийся qrcode.react, на белой подложке ради контраста в тёмной теме.
- Кнопка «Отсканировать QR» в форме активации. В Telegram используется
НАТИВНЫЙ сканер (в WebView камера через getUserMedia работает ненадёжно —
ровно то, из-за чего скан «в тг» и был проблемой), в вебе — html5-qrcode с
CDN, с фолбэком на фронтальную камеру и понятной ошибкой, если камеры нет.
- src/utils/qrScanner.ts: логика сканера вынесена из TvQuickConnect, чтобы её
мог переиспользовать любой экран. parseGiftCode понимает все три способа
распространения подарка (deep-link бота, ссылка кабинета, голый код с
префиксом GIFT- и без) и ОТКЛОНЯЕТ посторонние QR — иначе сканер подставил
бы в поле мусор с любой ссылки или Wi-Fi-кода.
- Веб-сканер гасится при уходе с вкладки и размонтировании, иначе индикатор
камеры остаётся гореть.
Локали ru/en/zh/fa, +4 теста на парсер.
Парная фронтовая часть к бэкенду (бот: 82609441).
- Поле «Лимит на пользователя» в форме создания партии: 0 — без
ограничения, для раздач и конкурсов ставится 1. Значение показывается в
карточке партии, если задано.
- Кнопка «Удалить партию» с подтверждением: отдельно от отзыва, который
лишь гасит ссылки. Если в партии есть погашенные купоны, подтверждение
предупреждает о потере истории активаций (выданные подписки не
отзываются). После удаления — возврат к списку.
- API: max_per_user в типах партии и запросе создания, deleteBatch.
Локали ru/en — раздел admin.coupons в zh/fa отсутствует целиком (купоны там
никогда не переводились), поэтому новые ключи добавлены в том же объёме.
Парная фронтовая часть к /cabinet/branding/bot-start-video (бот: 524960c3).
В «Брендинге» появилась карточка: загрузить/заменить/удалить видео, которое
бот прикрепляет к сообщению /start вместо картинки-логотипа, и статус
текущего состояния. Файл разово уходит в Telegram ради file_id — на нашей
стороне не хранится.
Видео в рассылках уже работало (кнопка в боте, загрузка в кабинете,
доставка send_video) и не затронуто. Локали ru/en/zh/fa.
Фронтовые хвосты автопродления Lava (бэкенд: de3518b7).
- Поле «Продукт Lava» в форме создания/редактирования тарифа: раньше
lava_product_id можно было задать только через API, из-за чего фичу нельзя
было включить из интерфейса. Пустая строка отвязывает тариф от продукта.
- CTA «Оформить с автооплатой Lava» в форме покупки тарифа — рядом с
СБП-кнопкой, в обеих ветках рендера; флаг lava_recurrent_enabled из
purchase-options наконец получил потребителя.
- API-метод purchaseWithLavaRecurring + типы lava_product_id в списке,
детали и запросах тарифа.
- Локали ru/en/zh/fa: подписи покупки и поля продукта (плейсхолдеры сверены).
Парная фронтовая часть к эндпоинтам /cabinet/subscription/lava-recurrent
(бот: 0dea2182). Блок — сиблинг Platega-блока с той же семантикой состояний
(off/pending/active/past_due), поллинг раз в 8с пока привязка PENDING.
Отличие от Platega в подписи: у Lava период задан продуктом в кабинете
провайдера и приезжает числом дней, поэтому канонические значения (30/90/365
и т.д.) показываются словами, а произвольные — как «раз в N дн.».
utils/lavaRecurring.ts: строгое распознавание 403 'Lava recurrent disabled'
(другие 403-guard'ы прятать нельзя), деградация неизвестного статуса в off.
Локали ru/en/zh/fa (+25 строк каждая, плейсхолдеры сверены). 7 тестов утилиты.
Свотч и превью-чип стиля primary красились в bg-accent-500 — акцент темы
кабинета, который перекрашивается (у оранжевой темы «Синий» выглядел
оранжевым). Реальный цвет кнопки задаёт Telegram Bot API: primary — синий
независимо от темы кабинета, поэтому свотч теперь фиксированный #54a9eb
(тот же телеграм-синий, что у кнопки Telegram-логина).
common.units.mo и common.units.days не существуют ни в одной локали — en/zh/fa
видели русский фолбэк «мес»/«дней», а PR #524 расширил видимость строки
«/мес» (периоды 31–44 дней). subscription.month и subscription.days есть во
всех четырёх локалях и уже используются карточкой периодов тарифа.
Сегмент выбирался вслепую — в списке не было числа пользователей, а после
отправки экран показывал только количество созданных офферов: сколько
человек реально получило предложение и сколько заблокировало бота, узнать
было негде.
В селекте сегментов теперь стоит охват каждого (GET /promo-offers/segments),
под ним — сколько уйдёт по выбранному. После отправки экран результата
показывает прогресс доставки с карточками Всего/Отправлено/Заблокировали/
Ошибки и опрашивает запись рассылки раз в 3 секунды, пока она не завершится.
Прогресс-блок и бейдж статуса вынесены из AdminBroadcastDetail в
BroadcastDeliveryStats и переиспользуются обеими страницами, а условие
«доставка ещё идёт» — в утилиту broadcastStatus с тестами.
Для периодов короче месяца в карточке периода под ценой выводилась
та же сумма с подписью «/мес»: цена за 7 дней показывалась как цена
за месяц. Причина — деление на max(1, days / 30), которое для коротких
периодов даёт делитель 1.
Расчёт вынесен в getMonthlyPriceKopeks: месячная ставка считается
пропорцией (price * 30 / days) и не показывается для периодов в месяц
и короче, где она либо дублирует цену, либо вводит в заблуждение.
Тот же хелпер применён на экране продления, где месячная цена для
периодов вроде 45 дней считалась делением на округлённое число
месяцев.
Аудит локалей кабинета с русским в качестве эталона.
Битые {{плейсхолдеры}} в zh/fa (рендерились как литеральные скобки,
теряли значение или дублировали то, что и так выводится в JSX):
- gift.sentTo / gift.activatedBy: неверное имя переменной
({{name}} → {{recipient}} / {{username}})
- dashboard.devicesConnectedUnlimited: {{count}} → {{used}} (+ «без лимита»)
- dashboard.maxUsage, gift.deviceCount, gift.activateSuccessDesc: потерянные
значения возвращены
- dashboard.expired.activeUntil, subscription.trialInfo.remaining: убран
{{date}}/{{count}} — значение выводится отдельным элементом
- trialInfo.description, trialOffer.freeDesc/paidDesc, gift.shareText:
переписаны без {{days}}/{{price}}/{{code}}, которые код не передаёт
- wheel.payWithStars: одинарные {stars} (i18next их не подставляет) убраны
Мисперводы zh/fa (разошлись по смыслу с ru/en):
- subscription.cta.*Hint, expiredBanner.selectTariff, trialUpgrade.description,
reduceDevicesDescription, menuEditor.customLabelsHint, myGiftsEmptyDesc,
partners.settingsFields.*, remnawave.overview.bandwidth, shareModalActivateVia
fa admin.pinnedMessages: 40 строк были на английском → переведены на фарси.
zh common.all: 'All' → '全部'.
en admin.broadcasts.subtitle: устаревшее «History and management» →
соответствует ru «Массовая отправка сообщений пользователям».
Плейсхолдеры и синхронность en/ru проверены (locales.test.ts).
