История обновлений

Главное

Два независимых улучшения, накопившихся с момента релиза 1.30.0:

• В админке появился раздел «Новости» для управления уже импортированными записями.
• Вебинары теперь индексируются не раз в сутки, а каждые 3 часа — добавленные днём вебинары попадают к студентам в тот же день, а не на утро следующего.

Что нового

Админка новостей

Администратор открывает «Админ-панель → Новости» и видит список всех новостей с поиском по заголовку и фильтром «все / только важные / только обычные». На каждой записи можно:

• Снять или поставить пометку «важная», задать срок её действия (important_until) — это критично если автоматический классификатор ошибся.
• Удалить ошибочно импортированную новость (например, дубликат из источника). Если источник её ещё содержит, при следующем парсинге запись может вернуться — об этом предупреждает confirm.

Редактирование текста / заголовка / картинки в этом разделе намеренно не предусмотрено: новости приходят из источников (VK-группа ЧувГУ, RSS, chuvsu.ru), любая ручная правка перезапишется при следующем парсинге.

Этот раздел закрывает класс задач вроде сегодняшней «новость про Dota 2 ошибочно стала важной» — теперь это снимается одной галочкой в админке, не SQL-командой.

Вебинары — индексация раз в 3 часа

Раньше расписание вебинаров пересчитывалось один раз в сутки в 03:00. Если кафедра добавляла вебинар уже после ночного парсинга, push-уведомление «начало через 5 минут» к студентам не приходило — в системе про этот вебинар просто не знали.

Теперь индексация повторяется каждые 3 часа (00, 03, 06, …, 21 МСК). Чтобы повторные запуски не порождали дублирующие push-уведомления (8 раз в сутки про один и тот же вебинар × 70 тыс. студентов × два push-канала — это был бы кратный спам), каждая отложенная задача рассылки теперь дедуплицируется на уровне очереди по уникальному отпечатку вебинара со сроком действия 24 часа. Студент получает ровно одно уведомление, какой бы из восьми запусков sync'а вебинар ни увидел первым.

Что не вошло

Платформенные задачи, которые ведутся параллельно и в этот релиз не попали:

• Push-рассылка «крайней важности» — push + email одновременно, без возможности отключить и с ускоренным разливом для ЧС-сценариев (на паузе до отдельного решения).
• Точечное обновление symfony до версий с патчем 4 свежих CVE от 2026-05-20 (composer-audit падает с allow_failure — отдельный MR с bump'ом версий).

При формировании release notes применялись средства автоматизации

Главное

Исправлен редкий случай, когда новости со словами, начинающимися на «Дот…» (например, про турниры по Dota 2 или дотации), ошибочно помечались как «крайне важные» и рассылались push-уведомлением всем студентам.

Что нового

Авто-классификатор важных новостей теперь сравнивает ключевые слова по границам слова, а не как подстроку. Раньше слово «ДОТ» (дистанционные образовательные технологии) случайно срабатывало внутри любого слова, содержащего сочетание «дот» — отсюда и сегодняшний инцидент с новостью про победу в киберспортивном турнире.

Под капотом — переход с str_contains на регулярное выражение с Unicode-границами слова, корректно работающее с кириллицей. Добавлены тесты, перекрывающие сегодняшний инцидент и аналогичные false-positive («дотация», «дотошный», «ЕВРАЗИЙЧСКИЙ»), а также подтверждающие, что настоящие срабатывания на «ДОТ.», «ДОТ,», «(ЧС)», «ВНИМАНИЕ!!!» продолжают работать.

Что не вошло (отдельно)

• Сама новость про Dota 2 уже лежит в базе с пометкой «важная» и push-уведомления уже разосланы — фикс предотвращает повторение, но не откатывает прошедшее. Снять пометку можно вручную в готовящемся админском разделе /admin/news (выкатится в 1.31.0) или одной SQL-командой до того.
• Расширение словаря ключевых слов и обновление зависимостей symfony (для свежих CVE) — отдельные задачи.

При формировании release notes применялись средства автоматизации

Главное

Восстановлена возможность открывать страницы своих заявок на справки и скачивать готовые документы. После выпуска версии 1.30.1 студенты, заходившие в раздел «Документы» и открывавшие конкретную заявку, получали ошибку сервера 500.

Что было не так

В разделе с готовыми документами кнопка «Скачать» строилась через генератор подписанных временных ссылок, который не знал о появившейся в апреле системе ролевых URL (/student/*, /teacher/*). Из-за этого Laravel не находил нужный маршрут и отдавал ошибку. Сама заявка, файл и логика скачивания при этом не пострадали — проблема была только в одной строке формирования ссылки.

Как починили

Имя маршрута завернули в существующий хелпер account_route_name(), который сам подставляет нужный префикс роли (student. или teacher.). Тот же хелпер уже используется в десятках других мест проекта, теперь он применяется и для подписанной ссылки на скачивание документа.

Что увидит пользователь

• Страница /student/documents/{категория}/{uuid} снова открывается.
• Кнопка «Скачать» отдаёт PDF/документ за обычное время.
• Готовые электронные подписи к документам тоже снова скачиваются.

Технические детали

• GlitchTip issue #5431 — после деплоя 1.30.2 должна закрыться, новых вхождений не ожидается.
• Затронут один файл: resources/views/student/documents/item.blade.php (две строки).
• Структура routes/web/student.php и DocumentsController не менялись.

При формировании release notes применялись средства автоматизации

Что в этом релизе

Микро-исправление перед публикацией версии 1.30.0 на прод. Из текста Политики конфиденциальности убраны три вспомогательных пометки «(уточняется)», предназначавшиеся для правового управления и не нужные конечному пользователю:

• в разделе о сроках хранения данных
• в разделе об удалении учётной записи
• в разделе об обработке данных несовершеннолетних

Содержательная часть этих разделов осталась без изменений: ссылка на ГОСТ, контактный e-mail и 30-дневный срок, упоминание возраста 14 лет.

Точные регламенты ЧувГУ по этим вопросам будут добавлены отдельным обновлением, когда правовое управление их пришлёт.

Полный список изменений

Релиз 1.30.1 объединяет содержание 1.30.0 (полная переработка Политики конфиденциальности) и микро-фикс выше. Версия 1.30.0 фактически не выкатывалась — её сразу заменил 1.30.1.

При формировании release notes применялись средства автоматизации

Главное

Опубликована новая редакция Политики конфиденциальности — впервые с августа 2022 года. Документ полностью переписан под текущую цифровую инфраструктуру университета и приложение «Мой ЧувГУ».

Что нового

Документ разделён на две независимые версии — для веб-сайта и для мобильного приложения. Каждую можно открыть в разделе «Документы» или по ссылкам в подвале портала. Появился английский перевод для иностранных студентов — переключение по ?lang=en или автоматически по выбранной локали интерфейса.

В тексте теперь даны ссылки на сами федеральные законы (152-ФЗ, 242-ФЗ, 273-ФЗ, 149-ФЗ), а рядом — короткие пояснения простым языком: что именно этот закон означает для пользователя.

Подробно описано, какие данные действительно обрабатывает портал и приложение: единый вход «ЧувГУ Ключ», источники университета (БРС, личный кабинет, расписание, портал справок), чат поддержки через Bitrix24, регистрация ошибок, Хранилище учётных данных под PIN-кодом, push-уведомления через Firebase Cloud Messaging и RuStore, аналитика Яндекс Метрика и Mail.ru.

Из политики убраны упоминания сервисов, которые в действительности не подключены: Google Analytics, Yandex AppMetrica для веба, Discord, Одноклассники, платёжные системы — раньше они там были, но не соответствовали реальности.

Появилось оглавление и навигация по разделам. Из определения «согласия» можно сразу перейти на раздел о Хранилище учётных данных, из строки «как мы передаём данные третьим лицам» — на пункт с конкретным сервисом. Межстрочный интервал увеличен, блок документа выровнен по центру страницы — читать стало удобнее.

В контактах оставлен один универсальный адрес — online@chuvsu.ru, вместо разделения на «пользовательские» и «официальные».

Подставлены реальные сведения об операторе: учредитель — Министерство науки и высшего образования Российской Федерации, дата создания университета — 1 сентября 1967 года, лицензия на образовательную деятельность № 2276 от 19 июля 2016 года, телефон общей приёмной +7 (8352) 58-30-36.

Под капотом — корректные SEO-теги, Open Graph для социальных сетей, Twitter Card, canonical и hreflang для двуязычных страниц, полный набор иконок для всех платформ.

Что не вошло (отдельно)

• ОГРН, ИНН, КПП и регистрационный номер ЧувГУ в реестре операторов персональных данных Роскомнадзора — на публичной странице сведений в виде текста отсутствуют. Будут добавлены отдельным обновлением, когда правовое управление пришлёт данные.
• Конкретные сроки хранения по категориям обучающихся и работников — отмечены в тексте пометкой «уточняются».
• Регламент удаления учётной записи (требование Google Play и App Store) — нужно согласование процедуры с правовым управлением.
• Перевод на чувашский, арабский, хинди и китайский — отдельная задача, юридическую силу всё равно имеет русский текст.

При формировании release notes применялись средства автоматизации

Главное

На странице «Поток уведомлений» в админке теперь видно не только что отправлено за прошедшие 24 часа, но и что ожидается отправить в следующие 24 часа — оценочно, по среднему за последние 7 дней.

Что нового

Heatmap расширен с 24 колонок до 48: слева — факт за прошедшие сутки (как раньше), справа — прогноз. Между фактом и прогнозом виден разделитель и подпись «↓ прогноз». Прогнозные ячейки оформлены пунктирной рамкой и с пониженной насыщенностью, а число в них предваряется тильдой (~217), чтобы было сразу понятно: оценка, а не факт. В строке у каждой категории появилась колонка «Прогноз 24ч» рядом с «Факт 24ч».

Прогноз считается просто: для каждой пары (категория × час дня) берётся среднее число отправок в этот час за последние 7 дней. День недели в расчёт пока не идёт — это упрощение MVP, при накоплении данных можно перейти на «средние по последним 4 таким же дням недели» отдельной итерацией.

Цвет и насыщенность ячеек используют единую шкалу: максимум по объединению факта и прогноза. Так можно с одного взгляда сопоставить «фактический пик в 22:00 сейчас» и «ожидаемый пик в 22:00 завтра».

Что не вошло (отдельно)

• Минутная гранулярность («через 19 минут»).
• Прогноз на 7 дней вперёд.
• Учёт дня недели — нужно ≥ 28 дней истории, сейчас её пока меньше.
• Очистка notification_send_counts старше 30 дней.

При формировании release notes применялись средства автоматизации.

Что починили

Тёмная тема админ-панели стала читаемой

Под тёмной темой админ-страницы выглядели плохо: заголовки карточек и страниц, подписи показателей сливались с тёмным фоном. Сам тёмный фон работал, но текст оставался «дневной» — серый на сером. Поправили на системном уровне: в тёмной теме текст и границы переходят на светлые оттенки, заголовки белые, текст-подсказки (text-muted) — светло-серые. Светлая тема не изменилась.

Верхнее меню админки

• Длинные пункты («Жалобы на данные», «Поток уведомлений») больше не переносятся на две строки внутри активной кнопки — раньше из-за этого активный пункт вылезал за верхнюю границу меню.
• Если в меню много пунктов и они не помещаются по ширине, появляется аккуратная горизонтальная прокрутка. Полоса прокрутки в обычном состоянии полностью прозрачна, чтобы не привлекать внимание; тонкая полупрозрачная индикация появляется только когда курсор наведён на меню.

При формировании release notes применялись средства автоматизации.

Поправили вёрстку верхнего меню админки в тёмной теме: пункты теперь читаются, активный пункт подсвечивается, иконки видны на тёмном фоне. Светлая тема не затронута.

При формировании release notes применялись средства автоматизации.

Технический хотфикс: устранили возможный 500 при заходе на админ-страницы у пользователя без обычных ролей (student / teacher).

В проде такого почти не бывает — Keycloak обычно одновременно назначает student или teacher. Корнер-кейс выстрелил в тестах после добавления 1.28.0 и легко исправляется: helper выбирает первую роль пользователя, для которой целевой маршрут зарегистрирован. Если ни одна не подходит — fallback на student-префикс (он есть всегда).

Поведение для обычного пользователя не меняется.

При формировании release notes применялись средства автоматизации.

Что починили

Heatmap notifications-observability снова показывает данные

В разделе «Поток уведомлений» heatmap отображал только общую сумму справа от каждой категории, а сами почасовые ячейки были пустыми — даже когда уведомления реально отправлялись. Это было незаметно из-за того, что сводные показатели сверху страницы работали корректно.

Корень оказался в несовпадении строковых ключей между PHP и SQL при сопоставлении часовых интервалов (часовые пояса не сходились). Теперь сравнение идёт по единому формату без таймзоны — ячейки наполняются.

Убран блок «Запланированные задачи»

Решили, что cron-расписание само по себе не то, что нужно админу. Полезная картина — это «через N минут будет отправлено ~M уведомлений», основанная на исторических данных. Это совсем другой формат, оформим как отдельную задачу.

Очистили подсказку к heatmap

Убрали пример с конкретным временем («поток webinar в 23:00 виден сразу»). Это был перенос из release notes 1.26.0, в админ-интерфейсе он выглядел как фактическое утверждение, чем не являлся.

При формировании release notes применялись средства автоматизации.

Что починили и добавили

Карточка пользователя в админ-панели

В табе «Документы» отображалась только дата и статус заявки, а название категории заменялось прочерком. Теперь — корректное название (источник был один и тот же, ошиблись с именем поля). Заодно заработал фильтр по категории — раньше он молча показывал «все категории» из-за той же причины.

Поток уведомлений: heatmap читается яснее

Раньше заголовки колонок были просто часами 09, 10, 11 без даты, и из-за этого выглядело так, будто таблица показывает планируемые отправки на ближайшие сутки — хотя на деле она показывает прошедшие. Теперь под каждым часом видна дата DD.MM, но только когда сутки меняются — это сразу видно как переход. Последняя колонка подсвечена бейджем «сейчас», а над таблицей напрямую написано окно «с DD.MM HH:00 по DD.MM HH:00».

Новый блок «Запланированные задачи на ближайшие 24 часа»

Появилась таблица над heatmap'ом со списком того, что cron-scheduler собирается запустить в следующие сутки: время, через сколько, название задачи, само cron-выражение. Это удобно сопоставлять с фактическими отправками: если запланировано — а в heatmap не появилось, есть повод посмотреть логи воркеров.

Под капотом — сервис ScheduledTaskList, который читает App\Console\Kernel::schedule() и считает next-run каждого события через Cron\CronExpression. Битые расписания пропускаются с записью в лог, страница не падает.

При формировании release notes применялись средства автоматизации.

Главное

В админ-панели появилась полноценная карточка пользователя. Раньше поддержке приходилось переключаться между разными разделами, чтобы собрать картину по конкретному студенту: где-то заявки, где-то обращения, где-то приказы по статусу обучения. Теперь всё это в одном месте.

Что нового

Карточка пользователя

Сотрудник поддержки вводит почту студента — и сразу попадает на его страницу с пятью разделами:

• Профиль — ФИО, группа, факультет, курс.
• Документы — все заявки на справки с фильтром по категории.
• Приказы — зачисление, отчисление, восстановление, переводы. Источник — портал ЧувГУ; если он временно недоступен, раздел просто покажет «приказов нет», а не упадёт.
• Обращения — все support-tickets, в которых пользователь упомянут как заявитель.
• Жалобы на данные — все его сообщения об ошибках с привязкой к инцидентам.

Это закрывает базовый сценарий поддержки: «студент пишет — давайте быстро посмотрим что у него с данными».

Глобальный поиск в шапке админки

Появилась поисковая строка в верхней части любой страницы админки. Работает в двух режимах:

• Ввели полный email и нажали Enter → попали на карточку пользователя.
• Начали набирать текст → под полем выпадают подсказки из общих индексов (преподаватели, группы, новости, сервисы, контакты, документы). Клик — переход на соответствующую страницу.

Что не вошло (и почему)

Поиск студентов по части ФИО осознанно отложили. Поля ФИО и почта в базе хранятся в зашифрованном виде, поэтому привычный поиск «по подстроке» по ним не работает. Чтобы такой поиск появился, нужно отдельное индексирование с продуманными решениями по защите персональных данных, аудиту запросов и тому, какие поля попадают в индекс. Это отдельный релиз.

Также пока не добавляли расписание/оценки/контракт в карточку — это тяжёлые внешние запросы, добавим точечно когда возникнет потребность.

Под капотом

• Один Blade-view с табами, данные подгружаются только для активного раздела.
• UserController::search() теперь редиректит на карточку вместо рендера отдельной страницы поиска.
• Поиск ticket'ов идёт по complainants.user_id (автозаполняется при создании заявки), а не по email-hash — это устойчивее к Keycloak-пользователям без локального email-кэша.
• Глобальные подсказки переиспользуют существующий account.web-api.search.suggest (тот же endpoint, что у публичного поиска платформы).

При формировании release notes применялись средства автоматизации.

Второй хотфикс после 1.27.0

В 1.27.1 поиск через Scout стал резолвить движок ElasticSearch, но открылась вторая трещина того же класса: при первом обращении к админ-поиску всё равно отдавалось 500, теперь с другим сообщением.

Что починили

Админ-поиск снова работает. Подключённая нами библиотека matchish/laravel-scout-elasticsearch поделена на два сервис-провайдера. Один настраивает движок — он подключался автоматически. Второй биндит вспомогательные классы (включая «HitsIteratorAggregate», без которого Scout не умеет разбирать ответ ES) — и этот провайдер настроен как ленивый: подключается только при первом обращении к ES-клиенту через DI.

Публичный поиск ES-клиент инжектит → ленивый провайдер просыпается → всё работает. Админ-поиск идёт через Scout-trait, ES-клиент напрямую не запрашивает → ленивый провайдер не подключается → ошибка binding'а → 500.

Фикс — оба провайдера matchish теперь явно зарегистрированы в config/app.php и грузятся при старте приложения.

Извлечённый урок

При выкате 1.27.0 проблема была не воспроизводима ни локально, ни в CI: локально DI к ES-клиенту срабатывает (мы открываем страницы публичного поиска при разработке), в CI Scout-driver вообще выключен (NullEngine). Сразу два бага — конфиг и порядок инициализации провайдеров — сложили картину, в которой:

• сам трейт Searchable работает (engine extend срабатывает в boot)
• сам ES-клиент работает (когда запрошен)
• но конкретный путь «admin search через ::search()» падает на missing bind в lazy-provider

Для будущих фич с Scout: проверка на проде должна включать именно admin-поиск через trait в чистом сценарии, без предварительного запроса public-search.

При формировании release notes применялись средства автоматизации.

Хотфикс после 1.27.0

В 1.27.0 в админ-панель пришёл поиск через ElasticSearch — и через час после деплоя выяснилось, что любой поисковый запрос отвечает 500. Причина оказалась в старой настройке драйвера Scout, которая раньше нигде не использовалась. Заодно подчистили перегруженное верхнее меню.

Что починили

Поиск в админке снова работает. Конфигурация драйвера была настроена под другое имя движка, чем тот, что регистрирует наша библиотека ElasticSearch. До 1.27.0 поиск через Scout нигде не вызывался, поэтому проблема не проявлялась — теперь поправили на корректное.

Команда переиндексации заработала. php artisan search:admin-reindex падала с ошибкой про аргумент. Теперь правильно подбрасывает модели в нативный scout:import.

UX-улучшение

Верхнее меню админ-панели стало короче. Из основной навигации убрали «Операторы запросов» и «Push-тест» — оба пункта используются редко, мешали остальным разделам помещаться в строку. Сами страницы остаются доступны по прямой ссылке.

Знаем о проблемах, починим в 1.27.2

• Меню в тёмной теме оформлено небрежно — поправим стили.

При формировании release notes применялись средства автоматизации.

Главное

В админ-панель пришёл нормальный поиск, а у разработки появился способ понимать, насколько он хорошо работает.

Что нового

Поиск в обращениях и жалобах на данные

В разделе «Обращения» админ-панели поиск теперь понимает русскую морфологию и опечатки. Ищется не только по теме и почте заявителя, но и по описанию обращения и контексту из Битрикса.

В разделе «Жалобы на данные» поиск наконец работает — раньше поле было, но контроллер его не учитывал. Теперь по содержимому жалоб пользователей можно быстро найти нужный инцидент.

Поиск дружит со всеми фильтрами: статус, блок, измерение качества, severity.

Качество поиска — новая страница для администратора

Появилась страница /admin/search-quality со снимком за 7 дней:

• Объём поисковых запросов и их медианная задержка
• Доля запросов, по которым ничего не нашлось
• Топ-15 запросов, давших ноль результатов — главный сигнал к тому, что нужно расширять словарь синонимов и подкручивать морфологию
• Топ-15 самых медленных запросов
• Распределение по источникам и ролям пользователей

Это позволяет точечно улучшать поиск, опираясь на факты, а не на ощущения.

Под капотом

• ElasticSearch-индексы для обращений и жалоб с русским морфологическим анализатором
• Журналирование запросов через асинхронную очередь — ответ пользователю не задерживается
• Artisan-команда search:admin-reindex для одноразовой переиндексации существующих записей

Что дальше

Накопится статистика по «нулевым» запросам — добавим словарь синонимов под реальные кейсы (МПОИТ ↔ Институт информатики и подобные). Автоматическая очистка журнала старше 30 дней — в следующем минорном релизе.

При формировании release notes применялись средства автоматизации.

Что в этом обновлении

Вход в платформу стал безопаснее

Поправили техническое требование к авторизации через единую учётную запись ЧувГУ. Теперь обмен между нашим приложением и сервером единого входа защищён дополнительной криптографической проверкой по стандарту OAuth 2.1 — PKCE.

Что это значит: даже если злоумышленник каким-то образом сумел перехватить промежуточный код авторизации в пути, обменять его на токен доступа без секрета, который знает только наш сервер, он не сможет. Раньше эта защита была опциональной по протоколу — теперь она применяется при каждом входе.

Никаких действий со стороны пользователей не нужно: вход выглядит так же, шаг с подтверждением через ЧувГУ-логин не добавляется.

Технические детали

• bump: 1.26.0 → 1.26.1
• В KeycloakController (index / callback / InvalidStateException recovery) добавлен Socialite::driver('keycloak')->enablePKCE()
• Метод S256 (SHA-256), plain не используется
• Соответствует OAuth 2.1 / RFC 9700 / FAPI Security Profile
• Требование к Keycloak realm: «Proof Key for Code Exchange Code Challenge Method» = S256 (подтверждено перед деплоем)

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Команда видит поток уведомлений в реальном времени

В мобильном приложении ~70 тысяч человек, и при массовой рассылке (вебинар через 5 минут, новость о деканате, оценки за сессию) разом уходят десятки тысяч push'ей и писем. Раньше команда узнавала о всплеске уже постфактум — по жалобам пользователей или по нагрузке на серверы.

Теперь в админпанели появился раздел «Поток уведомлений» — таблица сверху показывает основные цифры за последние сутки (всего отправлено, пик за минуту, какие категории и каналы активны), ниже — топ по категориям, разбивка по каналам (email / FCM / RuStore / in-app feed), и наглядная heatmap «24 часа × категории».

По heatmap'у сразу видно: «в 23:00 ушло 217 уведомлений webinar_daily» — значит утром команда поддержки готовится отвечать на вопросы про вебинары. «В пик сессии оценки идут по 50/мин два часа подряд» — значит сервер источника надо проверить на устойчивость к этой нагрузке.

Данные обновляются в реальном времени — каждое успешное уведомление инкрементит счётчик в минутный bucket'е.

Технические детали

• bump: 1.25.0 → 1.26.0
• Новый Eloquent listener TrackNotificationSent слушает event Illuminate\Notifications\Events\NotificationSent, инкрементит counter атомарным upsert'ом
• Таблица notification_send_counts(category_key, channel, bucket_started_at(минута), count) с уникальным составным индексом
• Каналы нормализуются до коротких слагов: mail / fcm / rustore / redis
• Сервис NotificationSendStats агрегирует за 24h/7d окна для admin-страницы
• 10 тестов (6 unit + 4 feature) на агрегаты и listener
• Cleanup старых строк (>30 дней) — TODO 1.27.x

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Команда видит, какие проблемы данных горят сейчас

В админпанели появилась страница «Здоровье данных» с цифрами за последние сутки и неделю: сколько инцидентов открыто, сколько в среднем уходит времени от первой жалобы до решения, какие блоки данных дают больше всего жалоб. Команда поддержки и разработки заходит туда утром и видит общую картину — без необходимости перебирать инциденты вручную.

Жалобы автоматически выстраиваются по приоритету

Раньше инциденты в списке были просто отсортированы по дате последней жалобы. Теперь у каждого инцидента есть Priority Score — число, которое учитывает три фактора: сколько человек жалуются, насколько важен блок данных в платформе (расписание влияет на всех, новости — нет), и насколько критичен сам сбой (5 уровней Sev1–Sev5).

Список инцидентов теперь по умолчанию отсортирован так, что наверху самые «горящие». Команда не тратит время на ручную приоритизацию — формула делает это сама на основе фактов.

Sev — единый язык критичности

Каждому инциденту можно проставить уровень серьёзности от Sev1 (полный сбой критичного сервиса) до Sev5 (косметика). Это упрощает разговор внутри команды: «у нас Sev1 по расписанию, бросаем всё» — звучит однозначно, в отличие от «срочно, важно, ну прям сегодня бы посмотреть».

Технические детали

• bump: 1.24.0 → 1.25.0
• Priority Score формула: ln(max(N,1)) × Importance × Criticality × SeverityWeight по Monte Carlo + SRE
• Importance каждого блока — от 1.0 (расписание) до 0.3 (новости/контакты)
• 5 уровней Sev с экспоненциальными весами 16/8/4/2/1
• Backfill priority_score для существующих инцидентов в момент миграции
• Health-снимок: open_total, медианный TTR за 7 дней, Data Downtime, самый старый открытый инцидент
• +14 unit-кейсов на формулу и инварианты importance/severity

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

«Сообщить о проблеме» — теперь это не просто кнопка

В мобильном приложении скоро появится возможность сообщить о проблеме прямо из любого раздела: расписания, оценок, ПРС, профиля, экзаменов, контактов. Достаточно нажать значок, выбрать одно из трёх «устарели / неправильные / отсутствуют» — и всё. Текст можно не писать, потому что вместе с жалобой к нам автоматически прилетает технический контекст: какой блок данных, какой источник, когда последний раз обновился. Это снимает с пользователя необходимость объяснять, и точно говорит нам, где искать.

Команда видит инциденты, а не лавину сообщений

Жалобы, которые приходят про одну и ту же проблему в одном и том же часовом окне, автоматически объединяются в один инцидент по «отпечатку» (что за блок данных, какой источник, какое нарушение качества). На странице «Жалобы на данные» в админпанели мы видим не сотню одинаковых сообщений, а несколько инцидентов с приоритетом по количеству пострадавших и времени, когда проблема началась.

Это в первую очередь снимает шум, во вторую — даёт честные метрики: сколько инцидентов по расписанию в неделю, какие группы или факультеты страдают чаще, насколько быстро мы реагируем.

Что дальше

Следующая итерация: уведомления «ваша жалоба учтена, проблема устранена» в момент решения инцидента, и кнопка «Сбросить кэш источника» прямо из админ-карточки — чтобы команда могла одним кликом подтянуть свежие данные с портала или БРС вместо того, чтобы ждать срабатывания обычного интервала кэша.

Технические детали

• bump: 1.23.2 → 1.24.0
• POST /api/v4/data-issues с auth + throttle 60 req/min, dedup по sha256(block | source | dimension | hour)
• две новые таблицы (data_issue_incidents + data_issue_reports) с индексами под фильтры
• 47 unit-кейсов и 8 feature-кейсов на CI

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Меню админки наконец-то стало нейтральным

В 1.23.1 мы попытались перекрасить верхнее меню админпанели в нейтральный цвет, но правка не сработала — старое правило из темы FastPanel перебивало нашу. Поправили: теперь меню действительно серое, а активный раздел подсвечивается голубой плашкой. Карточкам разделов вернули верхний воздух, который тоже съедался темой.

Иными словами — то, что должно было прилететь в 1.23.1, теперь прилетело.

Технические детали

• bump: 1.23.1 → 1.23.2
• селекторы в admin-design-system.css приравнены к специфичности FastPanel-темы (.layout-horizontal .main-navbar, .card .card-header ~ .card-body)

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Админка стала спокойнее

Доводка после 1.23.0. Горизонтальное меню админпанели было ярко-синим — теперь оно нейтрально-серое, как остальные служебные интерфейсы платформы. Активный раздел подсвечивается голубой плашкой, чтобы было сразу понятно, где вы находитесь.

И карточкам разделов добавили воздуха внутри: заголовки больше не упираются в рамку, формы и таблицы стоят с понятным отступом сверху и сбоку. Глазам теперь комфортнее.

Технические детали

• bump: 1.23.0 → 1.23.1
• правки только в bridge-CSS, который натягивает токены дизайн-системы на тему админки

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Админка теперь в фирменном стиле платформы

Раньше разделы админки выглядели по-разному — каждая страница со своими отступами, цветами кнопок, формами. Подключили к админке те же дизайн-токены, которые мы используем в мобильном приложении и кабинетах: цвета бренда, единые радиусы у кнопок и панелей, типографика Ubuntu для заголовков и Roboto для интерфейсного текста. Раздел «Обращения», «Истории», «Пользователи» теперь выглядят как одна продуманная система, а не разные продукты на одном домене.

Тикетная система: рабочее место оператора, а не форма с полями

Раньше, чтобы перевести обращение из одного этапа в другой, оператор открывал выпадающий список со статусами, выбирал нужный и нажимал «Сохранить». Если поставили «Решена» — потом ещё отдельно нажать «Уведомить». Каждый переход — несколько кликов, всё перемешано с правкой темы и описания.

Полностью переделали страницу обращения по образцу профессиональных тикетных систем:

• Этапы видны сразу. Сверху страницы — таймлайн «Создан → Принят в работу → Решён в релизе → Закрыт» с реальными датами. Видно, где сейчас обращение и какие этапы пройдены.
• Действия — отдельными кнопками. Не «выбрать из списка и сохранить», а нажать «Принять в работу», «Решить в релизе X.Y.Z», «Закрыть». Кнопка показывается только если переход возможен из текущего этапа. Решение в релизе автоматически отправит уведомления всем обратившимся.
• Ссылка для пользователя — одной кнопкой. Раньше оператор должен был руками собрать подписанную ссылку и вставить в Bitrix-чат. Теперь в карточке обращения готовая ссылка с кнопкой «Скопировать» — клик, и она в буфере обмена. Действует 60 дней.
• Контекст обратившегося под рукой. Справа в карточке — ФИО, роль, учебная группа, дата регистрации в платформе и счётчик его прошлых обращений. Не нужно переключаться на раздел пользователей, чтобы понять, кто пишет.

Технически

• bump: 1.22.2 → 1.23.0
• новые поля support_tickets.in_progress_at и support_tickets.closed_at для таймлайна; миграция бэкфилит существующие записи по приближениям
• разрешённые переходы между статусами описаны явно в SupportTicketStatus::allowedTransitions() и проверяются и в UI, и на сервере; добавлено 23 теста на покрытие
• CSS-токены ЧувГУ Design System (tokens-light.css) подключены в admin layout; bridge натягивает их на Bootstrap admin-тему, оставляя сетку и навигацию нетронутыми

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Раздел «Мои обращения» снова открывается

На странице /account/support/tickets был баг ещё с момента, когда мы переносили её в общий раздел для студентов и преподавателей (это было пару дней назад). Технически страница рендерила обёртку шапки, скрипты — но сам список обращений выводился в одну ячейку, а сама ячейка не была подключена к странице. Получалась почти пустая страница.

Поправили: страница теперь подключена к тому же шаблону, что и остальные разделы кабинета — с шапкой, меню и нормальным содержимым.

Под капотом: автоматический тест, чтобы такого больше не было

Эта ошибка не должна была дойти до пользователей — поэтому добавили автоматическую проверку, которая обходит все страницы платформы и валит сборку, если кто-то снова перепутает «куда подключать содержимое». В прод такой код больше не уйдёт.

Технические детали

• bump: 1.22.1 → 1.22.2
• resources/views/account/support_tickets/index.blade.php: @extends('layouts.account') вместо layouts.app — секции теперь совпадают
• новый архтест tests/Unit/Views/LayoutSectionContractTest.php сканирует blade-views и валится при @extends('layouts.app') + @section('content')

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Push-уведомления о новых обращениях снова доходят до приложения

Когда оператор регистрирует ваше обращение в поддержку, мы стараемся связать его с вашим аккаунтом — чтобы кроме письма прилетел push в мобильное приложение. В 1.21.2 эта связка работала только в половине случаев: с уже существующими обращениями всё было хорошо (мы их дочинили миграцией), а вот новые обращения, оформленные после 1.21.2, могли остаться без связки и без push'а — приходило только письмо.

Поправили: связка теперь происходит надёжно в момент создания записи об обратившемся, до того, как она попадёт в базу. Существующие записи, у которых связка не успела пройти, починены автоматически при выкладке.

Если вы получили письмо «Ваше обращение №X зарегистрировано», но push не прилетел в приложение — теперь это исправится с любого следующего такого письма.

Технические детали

• bump: 1.22.0 → 1.22.1
• логика поиска пользователя по email переехала из мутатора Eloquent в creating observer — это гарантирует, что user_id попадёт в БД при INSERT
• миграция повторно проходит по обратившимся с user_id IS NULL и подставляет связку, если пользователь существует

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

История обновлений: дни вместо вала версий

На странице «История обновлений» каждый релиз был отдельной карточкой со своей строкой даты. За день из платформы выкатилось несколько обновлений (бывает, что одно из них тут же исправляет неполадки в предыдущем) — и получалось, что одна и та же дата повторяется в списке восемь-девять раз подряд. Выглядело как «непрерывный поток патчей», хотя по сути это работа одного дня.

Теперь страница группирует обновления по дню. Каждый день начинается с одной шапки с датой, а под ней — карточки обновлений этого дня, от самого свежего к более раннему. На сами тексты обновлений это не влияет: они остаются как были, и ссылки на конкретное обновление (например, в письмах «ваше обращение учтено в обновлении 1.X.Y») продолжают работать как раньше.

Применяется ко всей истории сразу — не только к новым обновлениям.

Технические детали

• bump: 1.21.2 → 1.22.0
• группировка происходит на этапе рендера страницы — данные о релизах из GitLab API не меняются

При формировании заметок применялись средства автоматизации.

Что в этом обновлении

Дочинили опознавание зарегистрированных пользователей

В 1.21.1 мы починили часть случаев, когда уже зарегистрированный в платформе пользователь в карточке обращения оператора подсвечивался как «внешний». Но не все — у нас несколько лет аккаунты создаются через единую учётную запись ЧувГУ, и почта в карточке профиля не всегда совпадает с тем, как она хранится для входа.

Теперь связка идёт по тому же принципу, что и вход на платформу: если у пользователя есть аккаунт — мы его найдём, независимо от того, как почта записана в его карточке. И push-уведомление о регистрации обращения уйдёт ему в приложение, а не превратится «просто в письмо на email».

Существующие записи в системе автоматически дочинились миграцией при выкладке.

Технические детали

• bump: 1.21.1 → 1.21.2
• миграция повторно перевязывает обратившихся к их аккаунтам по канонической схеме (login = md5(lower(email)))

При формировании заметок применялись средства автоматизации.

Что нового

Внутренние пользователи — это «свои», а не «внешние»

В админке на странице обращения в поддержку зарегистрированные пользователи иногда подсвечивались плашкой «внешний» — это была ошибка сравнения почт. Теперь имеющиеся в системе аккаунты находятся корректно, даже если в базе у них почта с другим регистром.

«Обращения» теперь в админ-меню

Раздел тикетной системы виден прямо в горизонтальном меню админпанели рядом с «Операторами запросов». Раньше попасть туда можно было только по прямой ссылке.

Если обращений ещё нет — теперь понятно, что делать

Открываете «Мои обращения», а там пусто? Раньше была сухая плашка. Теперь — карточка с приглашающим текстом и кнопкой «Обратиться в поддержку», которая ведёт прямо на страницу контактов.

Уведомление о регистрации обращения

Когда мы оформляем ваш запрос в поддержку как обращение или добавляем вас в уже существующее — на почту приходит письмо «Ваше обращение №X зарегистрировано». В письме персональная ссылка, по которой можно следить за статусом, она действует 60 дней. Если у вас есть аккаунт — параллельно прилетит push-уведомление в мобильное приложение.

Технические детали

• bump: 1.20.0 → 1.21.1
• миграция автоматически перевязывает существующие записи обратившихся к их аккаунтам (по почте без учёта регистра)

При формировании заметок применялись средства автоматизации.

1.20.0 — теперь одну проблему мы регистрируем один раз

Что нового

Одна заявка может быть от нескольких человек. Раньше, если та же проблема пришла от трёх студентов — оператор поддержки заводил три отдельные заявки и три раза описывал то же самое. Теперь — одна заявка, в которую можно добавить email'ы всех обратившихся. Когда мы это починим — все трое получат письмо и push-уведомление.

Что это значит для вас как пользователя

Если вы написали в поддержку о той же проблеме, что и ваши однокурсники — нас не выматывает дублирование. И вы все одинаково быстро узнаете, что обновление вышло: одно письмо, одна ссылка, одни и те же подробности обновления.

Что это значит для команды поддержки

В админке появилась динамическая форма «+ Добавить ещё email». На странице заявки виден список всех обратившихся, дату уведомления каждого. Удалить случайно добавленного можно одной кнопкой; последнего удалить не даст — у заявки должен оставаться хотя бы один получатель.

При формировании release-notes применялись средства автоматизации

1.19.0 — заявка пользователя теперь автоматически закрывается с релизом

Что нового внутри команды

Раньше: оператор поддержки руками отмечал каждую решённую заявку — статус «Решена», тег обновления, кнопка «Уведомить». Десятки заявок за релиз — десятки кликов.

Теперь: оператор просто пишет в заявке номер планируемого обновления (например, «1.20.0»). Когда мы выпускаем это обновление — система сама переводит заявку в «Решена», ставит дату, отправляет письмо и push-уведомление автору. Без участия оператора.

Что это значит для пользователей

Письма со ссылкой «Ваше обращение учтено в обновлении» приходят моментально — в ту же минуту, как обновление вышло. Никаких задержек «оператор не нажал кнопку».

Если вы зашли в раздел «Мои обращения», и видите тег обновления у заявки — значит, мы уже включили её в план. Когда выпустим — обновим статус автоматически.

Что это значит для команды

• Меньше ручных кликов после каждого релиза.
• Невозможно «забыть нажать кнопку» — всё проходит автоматически.
• Если что-то пошло не так (например, тег пушнули, но фикс ещё не в нём) — повторный push тега или ручное «уведомить ещё раз» работают идемпотентно: пользователь не получит дубль письма.

При формировании release-notes применялись средства автоматизации

1.18.1 — починили доступ к разделу «Мои обращения»

Что починили

Раздел «Мои обращения» открывается у всех. В прошлой версии страница работала только по адресу /student/..., и преподаватели не могли её открыть — получали ошибку 404. Теперь раздел доступен любому авторизованному пользователю через единую ссылку «Мои обращения» в меню профиля (правый верхний угол).

Ссылка из письма теперь открывается без входа. Если мы написали вам про закрытое обращение — в письме теперь есть кнопка «Открыть обращение», которая откроет вашу заявку напрямую, без необходимости логиниться. Ссылка действительна 60 дней.

Что нового

В выпадающем меню профиля появился пункт «Мои обращения» — туда вы попадаете одним кликом, чтобы посмотреть статус своих заявок в поддержку.

Что это значит для вас

Не нужно гадать, куда зайти, чтобы увидеть, как идут дела по вашей заявке. Открыли меню — увидели список. А когда заявка решена — пришло письмо со ссылкой на конкретное обновление и кнопкой «Открыть обращение».

При формировании release-notes применялись средства автоматизации

1.18.0 — обращения в поддержку теперь под контролем

Что нового

«Мои обращения» в кабинете. Если вы писали в поддержку — в разделе «Мои обращения» теперь видно, что мы оформили ваше обращение в работу. Когда оно будет учтено в обновлении, статус сменится на «Решена в релизе», и вы получите письмо + push-уведомление с ссылкой на конкретное обновление.

Письмо с разъяснением, что починили. Раньше вы могли долго не узнавать, что обращение учтено. Теперь мы пишем напрямую: «Ваше обращение «{тема}» учтено в обновлении 1.X.Y — подробности на странице История обновлений». Один клик — и вы видите, что именно поменялось.

Как это работает

1. Вы пишете в поддержку — в Bitrix-чат, по почте или через приложение
2. Оператор регистрирует обращение в системе
3. Команда разработки добавляет ваш кейс в работу
4. Когда фикс выходит в релизе — система автоматически уведомляет вас письмом и push'ом

Что это значит для вас

Вы больше не теряете обращение в потоке чатов. Видите, на каком этапе оно сейчас. Узнаёте, когда оно решено — без необходимости спрашивать у поддержки «а когда же?».

При формировании release-notes применялись средства автоматизации

1.17.1 — мелкие правки на странице «История обновлений»

Что починили

Дата релиза больше не двоится. На странице с историей обновлений месяц в дате отображался криво — например, «12 маямаямая 2026 года» вместо «12 мая 2026 года». Поправили.

Название проекта подтягивается из настроек. Раньше в шапке страницы было жёстко прописано название — теперь оно берётся из единых настроек платформы. Если когда-нибудь поменяем название — текст обновится автоматически везде.

Что это значит для вас

Если зашли на страницу «История обновлений» и увидели странную дату — теперь она нормальная.

При формировании release-notes применялись средства автоматизации

1.17.0 — открытая история обновлений

Что нового

Появилась страница «История обновлений». Теперь любой посетитель сайта может найти её через ссылку «История обновлений» в нижнем меню — и увидеть, что мы поменяли в платформе за последние недели: что починили, что добавили.

Раньше эта информация была только у разработчиков. Теперь мы пишем заметки к каждому обновлению так, чтобы их мог прочитать любой студент или сотрудник: без технических терминов, простыми словами — что поменялось и почему.

Что это значит для вас

• Хочется понять, почему стало лучше (или, иногда, хуже) — посмотрите страницу, мы там пишем.
• Заметили проблему — напишите в поддержку. Скоро мы добавим возможность, чтобы вы узнавали, когда именно ваша заявка попадёт в работу.

Дальше

Готовим раздел, где мы сможем напрямую сообщать пользователю, что его обращение в поддержку учтено в конкретном обновлении — с письмом и push-уведомлением.

При формировании release-notes применялись средства автоматизации

1.16.2 — исправлены неполадки после обновления 1.16.1

В прошлом обновлении 1.16.1 мы убрали лишнее уведомление о вебинаре за 10 минут до начала (его дублировало уже существующее за 5 минут). После выкатки выяснились две неполадки, которые мы исправили этим обновлением.

Что мы починили

Письма о готовности документов снова приходят. После обновления 1.16.1 часть email-уведомлений о том, что документ готов к скачиванию, перестала доходить — внутренняя ошибка останавливала рассылку. Восстановили работу.

Напоминания о вебинарах не приводят к сбоям. Запланированные ранее напоминания, попавшие в обработку уже после обновления, могли вызывать ошибки в системе. Установили совместимый обработчик, который аккуратно пропускает такие задания.

Что это значит для вас

Никаких действий не нужно: исправления применились автоматически. Если вы заказывали документ через приложение и не получили письмо в последние сутки — теперь оно дойдёт при повторной попытке заказа.

1.16.1 — стало понятнее, как заполнять заявку на пересдачу

Что нового для студентов

Заявка на пересдачу подскажет, что писать в комментарии. Раньше комментарий деканату был необязательным — студенты не знали, что в нём обязательно должны быть фамилия, имя и отчество преподавателя. Без этой информации деканат отклонял заявку, и приходилось гадать, почему. Теперь форма прямо просит указать преподавателя и не даёт отправить заявку без комментария.

Что убрали

Лишнее напоминание о вебинаре. Раньше система присылала два push-уведомления подряд: за 10 минут до начала вебинара и ещё одно за 5 минут. Это создавало шум — два пуша об одном и том же событии. Оставили только напоминание за 5 минут.

Что это значит для вас

Заявка на пересдачу теперь не будет молча отклоняться: если вы забыли указать преподавателя, форма не даст отправить заявку и подскажет, что вписать в комментарий.

1.16.0 — переработали внутреннюю систему уведомлений

Что увидят пользователи

Меньше «мёртвых» галочек в настройках уведомлений. В разделе «Настройки → Уведомления» больше не отображаются категории, на которые мы технически не можем подписать пользователя (например, обновления, требующие данных, которых нам не передают). Если вы их раньше отключали — настройки сохранились автоматически.

Подписки на уведомления теперь надёжнее. Если вы отключали какие-то уведомления раньше — ваш выбор сохранился. Если вы подписывались, но не получали — теперь система знает, какие уведомления вам нужны, и доставляет их единообразно.

За кулисами

Внутри мы перестроили подсистему уведомлений: единый способ для всех типов писем и push-уведомлений, явные настройки видимости каждой категории и обязательные системные уведомления, которые нельзя случайно отключить (например, оповещения безопасности).

Что это значит для вас

Никаких действий не нужно: настройки уведомлений сохранены автоматически. Если в мобильном приложении вы видите немного меньше пунктов в настройках — это нормально, лишние пункты не работали.