bizproc 26.800.0: у шаблона появился источник происхождения, а ProcessStarter стал final

Бизнес-процессы готовят почву под шаблоны, которые создаёт не человек: в таблице шаблонов появилась колонка «откуда он взялся», запуск процессов вынесен в абстрактный класс, а сам ProcessStarter закрыт от наследования. В батче едет bizprocdesigner 26.400.0.

CREATE_SOURCE: откуда взялся шаблон

Новый enum Bitrix\Bizproc\Api\Enum\Template\CreateSource с двумя значениями и колонка CREATE_SOURCE varchar(32) NULL DEFAULT 'USER' в b_bp_workflow_template:

        use Bitrix\Bizproc\Api\Enum\Template\CreateSource;

CreateSource::User;      // завёл человек в дизайнере
CreateSource::Scenario;  // создан сценарием

    

Зачем — становится понятно из остального релиза: в модуле активно развивается генерация шаблонов AI-агентами (Internal\AI\Agent\Generator, системные ноды bitrix_ai_boss_report, bitrix_ai_project_pulse, CLI bizproc:ai-agent-reverse). Сгенерированный шаблон нужно уметь отличать от пользовательского — чтобы, например, перегенерировать его при обновлении и не затереть при этом то, что человек правил руками. Без метки источника такое решение принять невозможно.

Поле проброшено в ORM WorkflowTemplateTable, а copyTemplate() получил совместимый аргумент CreateSource $source = CreateSource::User.

Про базу важно: колонка добавлена в install/db/{mysql,pgsql}/install.sql, но отдельного ALTER в диффе нет. На живом портале этот SQL-батч колонку не допишет — она приедет отдельным механизмом обновления или при чистой установке. Если пишете свой код против CREATE_SOURCE, проверяйте наличие поля, а не полагайтесь на факт обновления.

Запуск процессов: рефакторинг с ломающим краем

Сценарии запуска вынесены из ProcessStarter в новый AbstractProcessStarter, а сам ProcessStarter стал final и наследует его. Имя класса осталось на месте, все публичные методы — тоже, так что вызовы не пострадают. Наследоваться от ProcessStarter больше нельзя. Если у вас был свой стартер поверх штатного — переезжайте на AbstractProcessStarter.

Заодно появился REST-сценарий запуска: StarterService::getStarterForManualRestDocumentScenario(), getProcessStarterForManualRestDocumentScenario(), getAutomationStarterForManualRestDocumentScenario() плюс Scenario::onRest. То есть документ, пришедший из REST, теперь стартует процесс своим путём, а не притворяется ручным запуском.

Рядом — связь между процессами: ParentWorkflowDto, BaseTypeStarter::setParentWorkflow(), Starter::setParentWorkflow(), ProcessStarterStacker, ScenarioProcessStarter. Активность «запустить процесс» (startworkflowactivity) теперь стартует через StarterService и передаёт ParentWorkflowDto — то есть дочерний процесс знает своего родителя. Ручной старт из bizproc.workflow.start/ajax.php тоже переведён на WorkflowTemplateService + StarterService вместо прямого CBPDocument::StartWorkflow(). Логика запуска перестаёт быть размазанной по компонентам и активностям.

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

• ProcessStarter стал final — наследники не соберутся.
• Internal\AI\Agent\Generator\AgentConfig\ConditionConfig::__construct — $object и $joiner поменялись местами, $object теперь обязательный и идёт первым. Позиционный вызов со старым порядком перепутает аргументы молча.
• Integration\AiAgent\Template и SetupTemplate потеряли processBeforeAction. Проверка фичи AI-агентов уехала внутрь экшенов (isRestartAvailable / isFillAvailable). Наследники, которые рассчитывали на хук контроллера, останутся без этой проверки — то есть без ошибки, но и без ограничения. Такое молчаливое ослабление проверки хуже фатала: обнаружится не сразу.
• В батче дизайнера: NodeCatalogItemDto::__construct получил обязательный ?int $contentBlockColor перед $properties. Позиционные new NodeCatalogItemDto(...) разъедутся.

Совместимые расширения (аргументы с дефолтом в конец): deleteAction(..., bool $deleteChatbots = false), startTemplate(..., ?int $userId = null), SetupTemplateService::fill(..., bool $skipAccessValidation = false, bool $applyDefaults = false), trySyncSection(..., bool $force = false).

Deprecated

Public\Activity\Trigger\ContextFields\TimemanStopWorktimeTrigger помечен @deprecated, замена — \Bitrix\Timeman\Integration\Bizproc\StopWorktimeTrigger. Логика переезжает в модуль, которому она принадлежит.

Мелочи с последствиями

• Дефолт опции workflow_dblock сменился с 'N' на 'Y', рядом появилась workflow_dblock_hold. Это блокировка на уровне БД при работе с процессом — включённая по умолчанию, она меняет поведение под нагрузкой. Если у вас были странности с параллельным исполнением процессов, здесь может быть и решение, и новая причина ждать блокировку.
• Опция очистки хранилища переименована: search_cleanup_days → storage_items_cleanup_days. Старое имя перестанет читаться.
• CBPGetUserActivity: ReserveUserParameter больше не обязателен в validateProperties().
• CBPHelper::stripUserPrefix() перестал падать на не-строках; группа ua резолвится через StructureHelper из humanresources.
• Регион cn для AI-агентов закрыт через Public\Service\AiAgent\RegionAvailabilityService; агенты bitrix_ai_day_planner и bitrix_booking_ai_call скрыты везде (AiAgentVisibility / HiddenAiAgentsRegistry).
• Новый агент SyncAiAgentNodesAgent::runAgent() раз в сутки и событие humanresources:OnAiReportsEnabled → EventHandler::onAiReportsEnabled.

Что делать

1. Ищите наследников ProcessStarter — переводить на AbstractProcessStarter.
2. Ищите наследников контроллеров AI-агентов, полагавшихся на processBeforeAction, — проверку нужно вернуть явно.
3. Проверьте опцию workflow_dblock на нагруженном портале.
4. Переименуйте search_cleanup_days в своих настройках.