Надежные интеграции, точный расчет отсутствий и умный мастер создания проектов

Поле "The next data update starts with" теперь корректно обновляется после успешного парсинга. Исправлена проблема с отсутствием записи о дате последнего парсинга для доски Linear в карточке редактирования проекта (таб "PM tools"): поле теперь автоматически заполняется временной меткой после успешного завершения синхронизации данных из Linear. Поведение приведено в соответствие с остальными интеграциями (Jira, GitLab и Notion), где это поле работало корректно.

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

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

Обязательные согласующие лица теперь корректно назначаются штатным сотрудникам при создании заявки. Исправлена проблема с автоматическим назначением обязательных согласующих: при подаче заявки на отпуск, отгул или больничный система теперь корректно применяет правила из раздела "Absence Settings → Mandatory approvers" и автоматически добавляет обязательных согласующих в список. Восстановлена логика автоматического назначения в соответствии с типом отсутствия и категорией сотрудника.

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

Исправлена ошибочная валидация последовательных отгуловп ри наличии большого временного разрыва между заявками. Устранена проблема, при которой алгоритм ошибочно блокировал заявку на 03.04.2026, ссылаясь на одобренный отгул от 09.03.2026, несмотря на 25-дневный разрыв между датами, многократно превышающий допустимое ограничение. Исправлен алгоритм подсчета интервала между заявками: теперь система корректно разграничивает действительно последовательные отгулы и заявки с существенным временны́м разрывом. Ограничение "не более двух отгулов подряд, следующий – не ранее чем через 3 рабочих дня" применяется только к заявкам, которые действительно следуют друг за другом.

Реализованы информативные состояния-заглушки для разделов "Summary" и "Transcription" с отображением статуса обработки. Добавлены четыре типа состояний для страниц карточки встречи и списка встреч:

1. "Processing in progress" – отображается во время генерации сразу после завершения встречи.
2. "Meeting processing in progress" – когда точное время обработки не определено,
3. "Oops! Something went wrong" с кнопкой "Retry" – при ошибках загрузки или генерации,
4. Состояние пустого списка встреч с описанием и кликабельной ссылкой на Enji Conference Bot и руководство по подключению.

На странице карточки встречи состояния-заглушки отображаются только в области контента (вкладки "Summary" и "Transcription"), сохраняя правую панель с информацией о встрече. На странице списка встреч заглушка занимает всю область контента и включает полный текст для первичной настройки, в том числе информацию о необходимости обращения в поддержку для подключения Conference Bot, если он не входит в текущий тарифный план.

Добавлен интерактивная подсказка "How it works?" с инструкцией по ConfBot-у на странице встреч. В заголовке страницы "Meetings" появилась кнопка "How it works?", по клику на которую открывается всплывающая панель с пошаговой инструкцией по использованию Enji Conference Bot: пригласите бота на встречу → дождитесь подключения → проведите встречу в обычном режиме → получите саммари и таймлайн обработки. Email бота является интерактивным элементом – при наведении подсвечивается как ссылка, клик копирует адрес в буфер обмена с уведомлением "Copied to clipboard" на 2-3 секунды. Адрес бота подгружается динамически в зависимости от инстанса. Панель поддерживает светлую и темную темы и закрывается кликом за ее пределами.

КАК ВЛИЯЕТ: Новые пользователи получают всю необходимую информацию для подключения ConfBot-а в один клик прямо на странице встреч – без необходимости искать инструкции в справочном центре.

Исправлено поведение UI при недостатке прав на переназначение встреч, добавлены новые права доступов. Устранены противоречивые сообщения об ошибках и непредвиденный переход со страницы "Meetings" при попытке переназначить встречу без необходимых прав. Теперь отображается единое понятное сообщение о недостатке прав, а пользователь остаётся на текущем экране без потери контекста. В схему прав доступа добавлены новые разрешения уровня "Meetings Admin" для ролей PM, DM, CTO и Stakeholder.

Поле "Final task statuses" перенесено с первого шага мастера на шаг подключения интеграций, восстановлена кнопка "Fetch Statuses". Поле "Final task statuses on the project board" убрано с шага "Add project" и перемещено в диалоговые окна подключения трекеров задач на втором шаге: теперь оно появляется после полей URL и учетных данных в окнах подключения Jira и Linear. Рядом с полем добавлена кнопка "Fetch statuses", которая активируется после заполнения обязательных полей подключения (URL и токен) и загружает список доступных статусов из трекера для выбора через мультиселект. 

При ошибке загрузки отображается встроенное сообщение об ошибке с сохранением возможности ручного ввода статусов через запятую. Для проектов типа Fixed и Ongoing установлено значение по умолчанию "Done", чтобы не нарушать расчёт метрик дашборда при отсутствии явного выбора. При добавлении нескольких подключений в одном окне каждое из них имеет собственное поле "Final task statuses" с кнопкой "Fetch". Поле остается обязательным – кнопка "Connect" недоступна до его заполнения. Тем самым устранена ситуация, когда пользователь на первом шаге должен был указывать финальные статусы, еще не зная, какой трекер подключает и какие статусы в нем существуют.

Улучшена обработка ошибок при загрузке статусов с некорректным ключом проекта. Теперь при указании неверного ключа проекта вместо технических ошибок "504 Gateway Timeout" или "Network Error" пользователь получает понятное сообщение "Invalid project key or no access: {PROJECT_KEY}". Реализована корректная обработка HTTP 404 от Jira REST API, который возвращается как при несуществующем проекте, так и при отсутствии прав на его просмотр. Это устраняет ситуацию, когда опечатка в ключе проекта приводила к непонятной технической ошибке, вынуждая пользователей гадать о причине и обращаться в поддержку.

Добавлена валидация ключа проекта в при проверке подключения доски. Проверка "Test Connection" в разделе "Edit project → PM Tools" расширена: теперь помимо доступности сервера и корректности учётных данных валидируется существование указанного ключа проекта и наличие прав доступа к нему. При ошибочном написании ключа "Test Connection" возвращает "Invalid project key or no access" вместо вводящего в заблуждение "Connection successful". Это предотвращает ситуацию, когда пользователь сохраняет доску с неверным ключом, не получает данных и не понимает причины.

Отключено автоматическое создание Agile-метрик при добавлении доски. При выборе финальных статусов в процессе добавления новой доски в разделе "Edit Project → PM Tools" больше не создаются три метрики Agile по умолчанию (Bug, Task, Story). Раздел "Agile Metrics" остается пустым – пользователь должен явно создать метрики с типами задач, актуальными для своего проекта. Это устраняет скрытое создание неработающих метрик с placeholder-названиями.

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

• "Could not reach the server. Check the URL and make sure it's accessible" – при недоступности сервера или некорректном URL.
• "Authentication failed. Check your username, token or API key" – при недействительных учётных данных.
• "Resource not found. Make sure the identifier is correct" – при неверном ключе проекта, репозитория или идентификатора.
• "Access denied. The user doesn't have permission to access this resource" – при отсутствии прав доступа.
• "Connection timed out. The server took too long to respond" – при превышении времени ожидания.
• "Something went wrong. Please try again or contact support" – для прочих непредвиденных ошибок.

Добавлена валидация формата URL с сообщением "Invalid URL. Enter the server base URL (e.g., https://example.atlassian.net), not a page link" для предотвращения ввода адреса страницы вместо базового URL. Все сообщения отображаются непосредственно рядом с полем, ставшим причиной ошибки.

Исправлена генерация ссылок на задачи в ответах PM агента. Реализован детерминированный этап обработки ссылок: PM-агент теперь автоматически преобразует все упоминания ключей задач в кликабельные Markdown-ссылки без участия языковой модели. Добавлена таблица диспетчеризации провайдеров с корректными URL-шаблонами для Jira, Linear и Redmine, защита уже существующих ссылок от повторной обработки, исправлен баг с захватом точки с запятой в URL трекера, обеспечена обратная совместимость для ранее сохранённых данных.

Исправлена передача идентификаторов проектов для периодических задач в глобальных чатах PM агента. Устранена проблема, при которой серверная часть отправляла пустой список project_ids для периодических задач, созданных "на все проекты". Это приводило к отсутствию данных при векторном поиске и невозможности обработки запросов. Теперь при выполнении периодических задач в глобальных чатах явно передаются все доступные идентификаторы проектов – по аналогии с чатами в рамках конкретного проекта. 

Восстановлен доступ PM агента к данным чатов проекта из BotFarm. Устранена проблема, при которой данные Slack и Telegram чатов успешно считывались и сохранялись через BotFarm, но PM агент не имел к ним доступа при ответах на вопросы о коммуникации команды. Исправлена конфигурация llm_factory с обеспечением корректных прав доступа. Теперь PM агент может отвечать на вопросы "о чем говорили вчера в проекте", "покажи обсуждения задачи X в Slack" и использовать контекст неформальной коммуникации для понимания договорённостей, блокеров и решений, которые зачастую фиксируются в мессенджерах, а не в документации.

Устранена проблема неполных ответов PM агента при запросах больших объёмов данных. Реализован новый модуль с функцией aggregate_large_result(): когда SQL-запрос возвращает более 100 строк (например, журналы работ 6 сотрудников за месяц – порядка 1 400 строк), система автоматически генерирует агрегирующий CTE-запрос, который сжимает данные до 18-50 строк через GROUP BY и string_agg() для текстовых колонок, сохраняя все ключи задач и описания внутри агрегированных строк. Добавлены системный промпт для агрегации, инструктирующий модель использовать конкатенацию вместо деструктивных SUM() и AVG(), а также юнит-тесты, покрывающие успешную агрегацию, ошибки выполнения и интеграционные сценарии. Тем самым устранена фундаментальная проблема, при которой языковая модель тихо обрезала ответ примерно до 16 000 символов, возвращая данные лишь по 2–3 сотрудникам из 6 запрошенных: теперь агрегация выполняется на уровне базы данных до передачи данных в модель, обеспечивая полное покрытие всех запрошенных объектов.

Исправлена логика определения статуса "Not in SoW" в отчетах по журналам работ (Worklog Report). Переработана проверка принадлежности к SoW: теперь метка "Not in SoW" присваивается только пользователям, физически не добавленным в запись SoW, – наличие нулевых ожидаемых часов (Expected hours = 0) на статус больше не влияет. Пользователь с показателем 0/0 часов, присутствующий в SoW, больше не помечается как "Not in SoW". Также устранена проблема кэширования статуса, из-за которой метка не снималась после обновления часов с нулевого значения до ненулевого. 

Добавлен учет часов отсутствия в отчёте по журналам работ. В колонке Total/Allocated для ежемесячных отчётов Worklog Report и Global Worklogs теперь отображаются часы одобренных отсутствий из модуля "Отсутствия". Рабочие дни определяются с учётом производственного календаря компании из расчёта 8 часов в день, дедупликация по календарному дню исключает задвоение при пересечении периодов отсутствия. При наличии часов отсутствия в ячейке отображается суффикс "+Nч отсутствия" – элементы выводятся в следующем порядке: фактические часы (жирным) → суффикс отсутствия при N > 0 → плановые часы (Allocated/SoW) справа. Строка "Total" в нижней части таблицы суффикс не отображает.