bizproc 26.900.0: установщик на миграциях и защита от unSign с мусором на входе

Релиз без единого изменения публичного API — api.diff пустой. Всё интересное в установщике: модуль переехал на UpdateSystem\Migration. Плюс пачка проверок типов там, где раньше подписанные значения из запроса шли в разбор как есть.

Установка описана декларативно

InstallDB / UnInstallDB больше не вызывают RunSQLBatch по install/db/*/install.sql и не регистрируют события и агентов напрямую — вместо этого installMigrations() / uninstallMigrations($dropTables). Приватный installAgents() (агент CreateRobotVersionIndex) из install/index.php удалён.

Что появилось:

• install/migrations/tables.php — описание таблиц модуля, включая b_bp_workflow_template.CREATE_SOURCE varchar(32) default 'USER' из предыдущего релиза;
• install/migrations/events.php — те же обработчики, что раньше жили в теле InstallDB (rest, forum, crm, ai, humanresources:OnAiReportsEnabled и другие);
• install/migrations/agents.php — StorageCleanupAgent, SyncAiAgentNodesAgent, CreateRobotVersionIndex;
• migration_config.json — defaultTableName = b_bp_workflow_template, маппинг install/components|js|activities.

Файлы install/db/*/install.sql в этом релизе ещё на месте — их удалят в 26.1000.0. То есть переезд сделан в два шага: сначала новый механизм рядом со старым, потом удаление старого. Разумная последовательность, если вы будете переводить свои модули.

Механику UpdateSystem\Migration и то, как её включить в модуль в /local/, разбираем отдельно.

Проверки типов перед unSign

По контроллерам и компонентам разошлась однотипная правка: перед unSign* проверяется is_array($documentType) или is_string(...SIGNED), а $_REQUEST['IFRAME'] читается через ?? null. Затронуты bizproc.automation, bizproc.debugger.start, bizproc.globalfield.edit|list, контроллеры debugger и globalfield.

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

Одно изменение вызова

DeleteStorageItemCommand в контроллере хранилища вызывается иначе: было ($storageTypeId, $id), стало ($id). Сам класс команды в этом диффе не менялся — то есть тип хранилища перестал быть нужен для удаления элемента. Если вы конструировали команду сами со старым набором аргументов, проверьте. В следующем релизе (26.1000.0) она поедет дальше — начнёт принимать массив id.

Прочее

• TemplateBuilder (генератор шаблонов AI-агента) добавляет lang-префикс к заголовкам активностей.
• CSS setup-template: класс ошибки поля и маркер обязательности в превью; стили deletedatastorageactivity вынесены в src/style.css.
• Правки шаблона bitrix_ai_project_pulse.

Что делать

• На работающем портале — ничего: публичного API релиз не меняет, схема тоже.
• Если ваш код искал bizproc/install/db/mysql/install.sql, знайте, что в следующем релизе файла не станет.
• Смотрите install/migrations/* этого модуля как на живой пример перед переводом своих модулей.