Sign 26.1000.0: процессы КЭДО, цепочка роботов и лимит в 1000 подписантов

Sign 26.1000.0 добавляет запуск кадровых процессов и цепочку роботов «черновик → настройка → отправка», обе возможности по умолчанию выключены. Одновременно появился жёсткий лимит в 1000 уникальных подписантов. На портале с крупными отделами проверьте массовую отправку документов до обновления.

Новое

Запускайте кадровый процесс на выбранных сотрудников

В разделе КЭДО появился каталог доступных процессов, форма старта, список запусков и повтор неудачного запуска. Триггер «Запуск из КЭДО» создаёт отдельный процесс для каждого сотрудника и передаёт EmployeeId, InitiatorId, StartedDate. В таймлайне документа появляется дело процесса; оно закрывается после завершения бизнес-процесса.

Для своей интеграции есть AJAX-действия sign.api_v1.b2e.process.listAvailable, startFields, start, list, retry, getByDocument. Они проверяют права чтения и добавления B2E-документов. Запуски проходят через очередь пачками по 20, агент обрабатывает её раз в минуту.

Флаг Feature::isKedoRunProcessEnabled() по умолчанию выключен. Одной портальной опции для включения мало: регион должен быть разрешён в service.b2e.run-process.publicity, а в поставке этого релиза там везде false. Если у вас скопирован шаблон sign.start, сверяйте его со штатным: появились страницы списка процессов и каталога.

Соберите подписание тремя роботами

В смарт-процессе цепочка B2E-действий делит создание документа на отдельные шаги:

1. «Создать черновик документа с сотрудником» (signb2edocumentdraftactivity) берёт файл из поля, выражения или Диска. Возвращает creationStatus, documentId, documentStatus, smartDocumentId; повторный запуск переиспользует созданный черновик.
2. «Настроить черновик документа подписания» (signb2edocumentconfigureactivity) задаёт компанию, провайдера, представителя, подписантов, внешний ID, напоминания и срок. Его можно вызывать несколько раз.
3. «Отправить на подпись созданный документ» (signb2edocumentsendactivity) завершает подготовку.

Например, между созданием и отправкой можно поставить своё согласование в том же процессе. Цепочка доступна только для CRM-документов типа Dynamic в режиме ROBOT+NODE и требует тарифной фичи sign_automation. По умолчанию она выключена; опция sign/SIGN_B2E_BIZPROC_CHAIN_ENABLED работает только там, где разрешены роботы B2E.

Источник создания сохраняется в документе: DocumentService::register() принимает необязательный CreationSource, а DocumentRepository::listByCreationSourceEntity() находит документы по исходному CRM-элементу. Это пригодится своей автоматизации, которой нужно связать документ с процессом.

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

Отдел больше 1000 человек не пройдёт выбор подписантов

MemberService::getUniqueSignersCount() и путь настройки участников теперь ограничивают выборку тысячей уникальных сотрудников. Считается общий набор из пользователей, отделов, списков подписантов и документов-источников. Если предел превышен, приходит SIGN_B2E_MEMBER_LIMIT_EXCEEDED. Отказавшихся подписантов исключают уже после проверки лимита, поэтому они тоже могут довести исходный набор до отказа.

Ограничение затрагивает мастер подписания, отправку по шаблону, копирование и fill-and-send. Разбейте крупную рассылку на документы с меньшим составом. Пустой выбор теперь возвращает SIGN_B2E_MEMBER_SELECTION_EMPTY, неверный тип — SIGN_B2E_MEMBER_SELECTION_INVALID.

AJAX-действия sign.api_v1.document.member.getUniqSignersCount и getUniqSignersCountForDocument передают эти ошибки клиенту. Вместо прежнего count: 0 на пустом выборе придёт ошибка; в успешный ответ добавлены totalCount и excludedCount. Обновите собственный JS, если он вызывает эти действия.

Учтите занятый документ и позиционные аргументы

MemberService::setupB2eMembers() отказывает документу в финальном статусе с SIGN_DOCUMENT_INCORRECT_STATUS. Параллельное изменение состава сразу получает SIGN_DOCUMENT_MEMBERS_BUSY: блокировка не ждёт освобождения. Для своего сервиса обрабатывайте этот отказ отдельно от неверного состава.

В конструкторе Bitrix\Sign\Item\Document перед $inviteMessage вставлены пять параметров источника создания. Если вы передаёте сообщение позиционно, перейдите на именованный аргумент inviteMessage:.

БД

В b_sign_document появились CREATION_SOURCE_TYPE, CREATION_SOURCE_ID, CREATION_SOURCE_ENTITY_TYPE_ID, CREATION_SOURCE_ENTITY_ID и индекс по паре типа и ID исходной сущности. Дополнительные сведения источника лежат в META.

Очередь процессов хранится в b_sign_process_launch, отдельные сотрудники и результаты запусков — в b_sign_process_launch_item. Своим отчётам доступны WORKFLOW_ID, STATUS и ERROR_MESSAGE по каждому сотруднику.

Мелочи и находки

• Бланк с расширением PDF в верхнем регистре теперь проходит проверку, как pdf.
• При сбое сервиса лицензий неудачный ответ кешируется на 60 секунд, чтобы каждый следующий вызов не ждал тот же таймаут.