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

Что нового

Срочные новости без собственной картинки теперь выделяются в ленте и мобильном приложении красной плашкой «ВНИМАНИЕ» вместо нейтральной серой заглушки.

Зачем

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

Детали поведения

• Плашка появляется только пока новость активна как срочная; после истечения срока важности новость возвращается к нейтральной заглушке.
• Если у срочной новости есть своя обложка от источника — она остаётся, плашка не подменяет её.

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

Откат при необходимости

Manual job rollback:production в pipeline 5164 возвращает версию 1.33.9.

Что починили

Новости с упоминаниями ракетной опасности, воздушной тревоги или эвакуации без отдельного маркера ВНИМАНИЕ теперь корректно помечаются как срочные — push приходит с маркером ‼ и приоритетной плашкой в ленте.

Что произошло

Сразу после деплоя 1.33.8 (нормализация Unicode-маркеров) выяснилось узкое место в самом словаре срочных слов: посты вроде «В Чувашии ракетная опасность» не содержали слова ВНИМАНИЕ и проходили мимо emergency-маркера. Дополнили словарь тремя фразами безопасности.

Что не меняется

• Логика, которая защищает от ложных срабатываний (бытовые контексты), сохранилась.
• Регулярка границ слова отсекает однокоренные слова: «эвакуатор», «эвакуационная учения» по-прежнему не помечаются как срочные.

Откат при необходимости

Manual job rollback:production в pipeline 5160 возвращает версию 1.33.8.

Что починили

Срочные новости с заголовком вроде ВНИМАНИЕ ‼ или ВНИМАНИЕ ❗ теперь снова доходят до студентов как срочные — с маркером ‼ в push-уведомлении и приоритетной плашкой в ленте.

Что произошло

После предыдущей правки логики срочных новостей (1.33.5) появилось узкое место: матчер срабатывал только если после слова ВНИМАНИЕ идёт обычный восклицательный или двоеточие. Реальные посты от авторитетных источников приходят с типографскими символами (двойное восклицание, fullwidth, эмодзи) и часто с пробелом перед маркером — такие посты по сути считались обычными и расходились без срочного push.

Сегодня это сказалось в момент, когда такая новость пришла в важной ситуации с БПЛА. Восстановили работу матчера для всех вариантов восклицания.

Что не меняется

• Логика, которая защищает от ложных срабатываний (вроде «привлёк внимание»), сохранилась.
• Список ключевых слов и регулярка границ слова — без изменений.
• Раздел справок, мессенджер, расписание — не затронуты.

Откат при необходимости

Manual job rollback:production в pipeline 5150 возвращает версию 1.33.7.

Hotfix-релиз 1.33.7

Обновление ansible/vault/production.env:

• Новые URL внешних сервисов мониторинга (bugtracker / GlitchTip) и обработки изображений (thumbor).
• Ротация THUMBOR-ключа подписи URL картинок.

Что меняется для пользователей

• Картинки в новостях и чате после деплоя загружаются с обновлёнными подписями.
• Внутренние ошибки приложения начинают приходить на новый адрес мониторинга.

Что не меняется

• Encrypted-данные пользователей (пароли BRS/LK в Credential Vault), сессии и push-токены — не затронуты. THUMBOR-ключ не пересекается с Laravel APP_KEY.

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

См. MR !440, !438, !439.

Развёртывание

Автоматическое через CI/CD Ansible job по тегу. Перезагрузка приложения штатная, downtime не предполагается.

Что починили

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

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

Что почувствует пользователь

• Студент при заполнении формы заявки на справку через деканат — увидит полный поясняющий текст в синих информационных блоках над полями. Никаких действий с его стороны не требуется.
• Веб-сайт обычного пользователя: не задето.
• Сотрудник админки: не задето.

Если пояснения всё ещё пустые

Если вы открыли страницу формы заявки до выкатки 1.33.6, обновите страницу (Ctrl+F5 для жёсткой перезагрузки). Если после этого пояснения всё равно пустые — напишите в поддержку с указанием типа заявки.

Технический контекст

Шаблон формы обращался к свойству объекта-сообщения, которое не существует — PHP молча возвращал пустое значение, и блок описания не рендерился. Фикс — приведение шаблона к актуальному API класса. Содержимое подсказок из config/documents.php не менялось; оно теперь корректно отображается.

Что починили

Студенты получали push-уведомление с маркером ‼ (двойной восклицательный — обозначает важное/срочное объявление) на новости, которые на самом деле к чрезвычайным ситуациям отношения не имели. Например, поздравительная новость про преподавателя университета, ставшего экспертом форума, приходила как срочное оповещение.

Причина — слово «внимание» в обычном литературном контексте («привлек внимание», «обратите внимание») автоматически срабатывало как маркер срочности. Теперь срочность определяется только по конструкциям с восклицательным знаком или двоеточием — то есть «ВНИМАНИЕ!» или «ВНИМАНИЕ:», как и принято в реальных экстренных сообщениях.

Что почувствует пользователь

• Студенты: больше не будут получать ложные ‼-push'и про обычные новости. Реальные срочные сообщения (эвакуация, отмена занятий, переход на ДОТ) продолжают приходить с маркером важности.
• Веб и админка: ничего не меняется снаружи.

Если предыдущие ложные пометки видны в ленте

Если в ленте новостей вы видите «важную» новость, которая на самом деле обычная — администратор может убрать пометку через админ-панель (/admin/news/{id}). Уже отправленные push-уведомления отозвать невозможно.

Внутренний контекст

Этот фикс продолжает линию работы над качеством классификации новостей (после 1.30.3 word-boundary матчинга). Логика matcher'а корректна — пересмотрен только словарь ключевых слов: слова обычной литературной речи без emergency-маркера теперь не приводят к ложному срабатыванию.

Что добавили

Если заявка на справку или выписку (через деканат) более 14 дней висит без ответа — сервер автоматически переводит её в финальный статус «Прекращено» и уведомляет студента push-сообщением с предложением обратиться в деканат напрямую.

Зачем

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

Теперь заявки старше 14 дней без ответа портала автоматически закрываются с понятным комментарием. Студент получает push, а в истории заявки видит причину и рекомендацию.

Что почувствует пользователь

• Студент с зависшей заявкой получит push: «Заявка высылалась в деканат более 14 дней назад, ответа не получили. Обратитесь в деканат напрямую для статуса заявки.» После этого можно подать заявку заново, если справка ещё нужна.
• Новые заявки работают как раньше — только если деканат не отвечает 14+ дней, статус закроется автоматически.
• Веб-сайт обычного пользователя: ничего не меняется.

Технический контекст

Авто-закрытие выполняется ежедневно в 04:15 МСК (после auto-cancel архивных категорий в 04:00). Закрываются только заявки с extradition=portal (через деканат), которые провели в PROCESSING более 14 дней. Финальный статус — TERMINATED. Закрытие необратимо, но всегда можно создать новую заявку.

Что НЕ в scope этого релиза

Эта проблема — следствие отдельного бага: подсистема синхронизации статусов с порталом деканата (SyncAllPortalStatusesJob) почему-то не подхватывает ответ от деканата для части заявок. Сам этот баг — следующая задача.

Что починили

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

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

Что почувствует пользователь

• Студент: новые заявки на документы теперь обрабатываются стабильно. Если у вас есть старая заявка в статусе «в очереди» — после ручной реактивации она продолжит движение и закроется ожидаемо в течение нескольких минут.
• Веб-сайт: ничего не меняется снаружи.
• Сотрудник админки: ничего не меняется снаружи.

Если ваша заявка всё ещё «в очереди»

Напишите в поддержку с указанием номера заявки. После 1.33.3 для каждой такой заявки админ реактивирует её через серверную утилиту (одна минута работы), и она доедет до результата.

Внутренний contekst

Завершает линию фиксов 1.33.0 → 1.33.1 → 1.33.2 → 1.33.3, связанных с миграцией Firebase, разделением stories-виджета и системой пересдач документов.

Что починили

Мобильное приложение крашилось при открытии истории заявки на пересдачу/документ (экран «История изменений статуса» внутри карточки заявки). Серверная часть отдавала числовое поле статуса в неправильном формате — приложение получало строку вместо числа и падало с технической ошибкой.

Зачем

В production-окружении модуль услуг работает на другой базе данных (PostgreSQL), которая по-другому интерпретирует числовые поля. Локально (MySQL) проблема не воспроизводилась, поэтому баг проскочил в продакшен с момента запуска фичи.

Что почувствует пользователь

• Студент в мобильном приложении: история статусов заявки теперь открывается без вылета. Можно посмотреть, на каком этапе застряла заявка.
• Веб-сайт: не задето.
• Сотрудник админки: не задето.

Если что-то не работает

Закройте приложение полностью (свернуть и убить из недавних) и откройте заново. Если экран всё ещё крашится — напишите в поддержку с указанием версии приложения и модели телефона.

Внутренний follow-up

В ходе фикса обнаружена смежная проблема: четыре event-listener'а на сервере имеют тот же скрытый pgsql-баг и могут не отрабатывать на production. Это может объяснять зависание некоторых заявок в статусе «в очереди». Следующий патч 1.33.3 закроет эту проблему отдельно.

Что починили

В админ-панели: при попытке открыть редактирование уже созданной истории/анонса страница падала с ошибкой. Теперь форма открывается корректно, видны все поля, можно сохранить изменения.

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

Зачем

Оба бага существовали ещё с того момента, как фичу историй и анонсов завезли в админку. Выявили их одновременно, когда понадобилось срочно добавить новый анонс — поэтому и патч общий.

Что почувствует пользователь

• Сотрудник админки: редактирование историй теперь работает (нужно перезагрузить страницу один раз после деплоя).
• Студент в мобильном приложении: лента историй на главном экране снова прогружается стабильно.
• Веб-сайт обычного пользователя: ничего не поменялось.

Если что-то не работает

Если в мобильном приложении виджет историй всё ещё ведёт себя странно — закройте приложение полностью (свернуть и убить из недавних) и откройте заново. Если не помогло — напишите в поддержку с указанием версии приложения и модели телефона.

Что нового

Обновили внутреннюю систему доставки пуш-уведомлений на современную версию. Для пользователей всё работает по-прежнему — нотификации о парах, оценках, новостях продолжают приходить как раньше.

Зачем это нужно

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

Что почувствует пользователь

• Веб-сайт: ничего не должно поменяться. Если пуши включены в браузере — они продолжают приходить.
• Мобильное приложение: вообще не задето этим релизом.

На что обратить внимание

Если после обновления вы заметили, что пуши на сайте перестали приходить — попробуйте: 1) выйти из аккаунта и зайти заново, 2) очистить кэш браузера, 3) переоформить разрешение на уведомления в настройках браузера. Если не помогло — пишите в поддержку, разберёмся.

Главное

Технический релиз качества и безопасности: обновили старый jQuery, перевели Firebase на локальные файлы, починили версию в URL ассетов. Видимых изменений в интерфейсе нет.

Что нового

Старый jQuery 3.4.1 (в нём, по публичной базе уязвимостей, было найдено повреждение объекта при разборе пользовательского HTML) заменён на актуальный jQuery 3.7.1. В админке этой версией мы пользуемся уже давно, теперь всё приложение работает на одной версии.

Скрипты Firebase (через которые приходят push-уведомления) раньше подгружались с серверов Google. Теперь они лежат прямо у нас, на нашем же домене. Это и быстрее — браузеру не нужно ходить на сторонний сервер — и не зависит от внешних сетевых сбоев у Google.

Версия в URL картинок и стилей (хвостик ?v=...) теперь жёстко привязана к номеру релиза. Раньше там иногда попадался артефакт сборки -dirty, который сбивал кэш браузера в неожиданных местах и выглядел странно в логах.

Что не входило

Полный переход Firebase на новый модульный API (v10/v11) — отдельная задача, делаем когда сложится время. На push-уведомления текущий релиз не влияет.

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

Главное

Технический патч безопасности: cookie долгоживущего входа через «ЧувГУ Ключ» снова шифруется на стороне сервера, как было до релиза 1.31.1. Видимых для пользователя изменений нет — на работу сайта и силент-обновление сессии это не влияет, последние корректно работают с прошлого релиза 1.31.2.

Что было

В 1.31.1 я ошибочно снял со служебной cookie долгоживущего входа дополнительный слой шифрования Laravel, посчитав, что одной подписи Keycloak достаточно. Подпись действительно защищает от подмены значения, но не от чтения содержимого: при любой утечке cookie через побочные каналы (логи с заголовками, ошибки middleware, дампы памяти) её внутренние поля можно было прочитать обычным base64-декодом. Это нежелательно — лучше когда таких возможностей нет вовсе.

Что сделано

Откат изменения 1.31.1: cookie снова шифруется стандартным механизмом Laravel cookie encryption. Поверх остаются прежние защитные атрибуты — HttpOnly, Secure, SameSite.

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

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

Ничего. Для уже залогиненных все продолжится бесшовно: на следующем запросе механизм восстановления заменит cookie на её зашифрованный вариант.

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

Главное

Если у вас вдруг пропала сессия (закрыли вкладку надолго, очистили часть cookies, истёк service-side cleanup), но в браузере остался долгоживущий вход через «ЧувГУ Ключ» — теперь портал тихо возвращает вас в сессию, а не выкидывает на главную с просьбой логиниться заново.

Что изменилось внутри

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

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

Параллельно поправлен один скрытый эффект: после успешного силент-обновления портал теперь правильно запоминает идентификатор сессии Keycloak — это нужно, чтобы команда «выйти из всех устройств» из «ЧувГУ Ключа» корректно отзывала восстановленные сессии тоже.

Что не входит в этот релиз

Эта правка — продолжение работы по силент-входу из 1.31.1. Платформенные доработки (рассылка крайне важных новостей, обновление symfony) — отдельные задачи.

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

Главное

Срочный фикс: студенты больше не разлогиниваются спустя 5–10 минут после входа. Силент-обновление сессии через Keycloak теперь работает как должно.

Что было

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

Что чинит фикс

За продление сессии без повторного ввода логина/пароля у нас отвечает специальная cookie с долгоживущим токеном Keycloak. Из-за конфликта с системой шифрования cookies в Laravel эта cookie иногда тихо «исчезала» из запроса при следующем обращении — портал не мог продлить сессию и просил войти повторно.

Точечная правка в одном файле снимает ненужное шифрование с этой конкретной cookie. Сам токен внутри всё равно остаётся криптографически подписанным самим Keycloak'ом, поэтому защищённость не страдает — наоборот, фикс убирает источник тихих падений.

Что не входило

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

Кому нужно перелогиниться

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

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

Главное

Два независимых улучшения, накопившихся с момента релиза 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 минут.

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

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