mail 26.800.0: массовые действия над ящиками и fail-closed привязка письма к посту

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

Массовые действия: зачем и как включить

На портале с сотней сотрудников включение CRM-интеграции каждому ящику вручную — это сотня заходов в карточку. Новые экшены закрывают ровно это:

        MailboxConnecting::massDisconnectMailboxesAction(array $mailboxIds)
MailboxConnecting::massSetCalendarIntegrationAction(array $mailboxIds, $enabled)
MailboxConnecting::massSetCrmIntegrationAction(array $mailboxIds, $enabled, ?array $crmOptions = null)

    

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

Включается фича опцией:

        \Bitrix\Main\Config\Option::set('mail', 'enable_list_improvements', 'Y');

    

Проверка — Feature::isMailboxGridBulkActionsAvailable(). По умолчанию N, то есть после обновления вы ничего нового в интерфейсе не увидите, пока не включите. Это стоит знать, прежде чем искать баг.

Результат операции возвращается как BulkActionResult с тремя списками: applied, skipped, failed. Хороший контракт для массовых операций — частичный успех виден явно, а не сваливается в один булев флаг.

Со стороны сервиса добавились MailboxConnector::enableCrmWithDefaults(), updateCalendarOptions(), updateCrmOptions(), со стороны грида — MailboxGrid::createPanel() и набор actions (Enable/DisableCrmAction, Enable/DisableCalendarAction, ConfigureCrmAction, DisconnectMailboxAction, JsPanelAction, MailboxPanelProvider).

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

Новый Secretary::bindFeedPostAction(int $messageId, int $postId, CurrentUser $currentUser) пишет UF_MAIL_MESSAGE через $USER_FIELD_MANAGER->Update('BLOG_POST', ...), а не через \CBlogPost::Update().

Разница существенная. CBlogPost::Update() — это полноценное обновление поста: события блога, пересчёт прав, потенциальная смена автора на того, кто выполняет операцию. Для того чтобы дописать одно пользовательское поле, это слишком много побочных эффектов. Прямое обновление UF трогает ровно то, что нужно, и автора поста не меняет.

Второе — экшен сделан fail-closed: успехом считается только случай, когда после обновления UF в MessageAccessTable действительно появилась запись для BLOG_POST. Не появилась — пишется AddMessage2Log и возвращается ошибка. Логика простая: привязка письма к посту — это раздача доступа к переписке, и «вроде записалось» здесь недопустимый ответ.

Установщик

InstallDB больше не гоняет install/db/{mysql,pgsql}/install.sql и не регистрирует обработчики через EventManager в index.php — всё ушло в install/migrations/: tables.php (b_mail_mailbox и остальные), events.php, agents.php (CMailbox::CleanUp() раз в сутки, AccessInstaller::install() каждые 60 секунд с лимитом 600). SQL-файлы удалены, добавлен migration_config.json.

Одна деталь для тех, кто мигрирует порталы: шифрование TOKENS на b_mail_oauth включается только при чистой установке после успешной миграции. На существующем портале само по себе не включится.

Что делать

• Хотите массовые действия — включите mail / enable_list_improvements.
• Пишете свои bulk-операции — посмотрите на BulkActionResult как на образец: applied / skipped / failed вместо true/false.
• Если у вас был свой код привязки писем к постам через CBlogPost::Update — это хороший повод переписать его на USER_FIELD_MANAGER и перестать переписывать автора поста.