mail 26.700.0: статистика писем для AI-ассистента и предупреждение о провайдерах

Модуль научился считать входящие по ящику или сотруднику за период и отдавать это AI-ассистенту как инструмент. Плюс появился слой ограничений по почтовым провайдерам. Основной риск обновления — не удаления, а вставка аргументов в середину конструкторов двух DTO.

Счётчик входящих и tool для ассистента

Новый MessageStatistics::getStatistics() возвращает MailStatisticsDto с incomingCount. Поверх него — GetMailStatisticsTool с ACTION_NAME = 'get_mail_statistics' для AI Assistant: ассистент теперь может ответить на «сколько писем пришло на этой неделе», не выдумывая цифру.

Два правила, зашитые в реализацию:

• Входящее — это письмо в входящих папках, определяется по DIR_MD5. То есть считается физическое расположение письма, а не флаг направления.
• mailboxId и employeeId вместе передать нельзя — tool вернёт ошибку. employeeId разворачивается в ящики владельца, но только те, что доступны текущему пользователю. Иначе через ассистента можно было бы посчитать чужую почту.

Права разруливает новый MailboxAccess с методами getAccessibleOwnerMailboxIds() и resolveUserMailboxIds() — тот же слой пригодится, если делаете свои отчёты по почте.

Ограничение провайдеров: Яндекс и Mail.ru

Появился ProviderAccessRestriction (isFeatureEnabled(), isRestricted(), resolveProviderName()), включается опцией mail / provider_restriction_notice = Y. Правила: для yandex ограничение показывается на бесплатных доменах (yandex.*, ya.ru, narod.ru), для mail.ru / mailru — всегда. Пользователь видит предупреждение в форме подключения ящика (попап provider-restriction-popup.ts).

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

Что сломается

Оба изменения — вставка параметров в середину, поэтому именованные аргументы переживут обновление, а позиционные молча разъедутся:

• SearchMessagesDto::__construct — перед $limit и $offset вставлены ?array $bindings = null и ?array $excludeBindings = null. Позиционный вызов отправит ваш $limit в $bindings.
• SearchMessagesByTasksRequest::__construct — вторым аргументом добавлен int $offset = 0, всё остальное сдвинулось.

TaskFinder::findTasksLinkedToMail() получил $offset = 0 в конец — этот совместим.

Если вы конструируете эти DTO, самое время перейти на именованные аргументы: тип у ?array и int разный, но при null в позиции $limit ошибки может и не быть — будет тихо неправильная выборка.

Что ещё появилось

• MessageFilter::addIncludeBindings() / addExcludeBindings() — фильтр по привязкам сущностей (это и есть те самые bindings в DTO).
• QueryBuilder::countMailMessages(), MessageSearch::count() — счётчик без выборки строк.
• DateTimeParser::getNullableLowerBound() / getNullableUpperBound() / validateRange() — разбор интервала дат с валидацией. Пригодился как раз для периода в статистике.
• У MessageByTaskSearch стали публичными buildMessageUrls, filterAccessibleRows, loadAccessByMessageTask, loadMessages — можно переиспользовать отдельные шаги, не гоняя весь поиск.

Что делать

1. Проверьте позиционные вызовы SearchMessagesDto и SearchMessagesByTasksRequest — это главный риск обновления.
2. Считаете почту сами — посмотрите на MessageStatistics и MailboxAccess, скорее всего свой код можно сократить.
3. Решите, нужен ли вам попап ограничения провайдеров (mail / provider_restriction_notice).