Нужно реализовать общесистемный модуль Automation для ИРБИС 128. Модуль должен позволить администраторам настраивать правила автоматизации без написания PHP-кода: trigger -> conditions -> actions -> execution policy.
Automation должен быть владельцем правил автоматизации, trigger/condition/action model, action whitelist, dry-run, explain, execution audit, защиты от циклов и интеграции с Queue. Модуль не должен становиться вторым workflow engine, не должен обходить Security и не должен содержать частную доменную логику Tasks.
Контекст
В промышленном контуре ИРБИС 128 автоматические реакции нужны задачам, workflow-проектам, событиям, очередям, согласованиям, публичным каналам и будущим доменным модулям. Если каждая предметная область будет реализовывать собственные обработчики, появятся разрозненные правила, неодинаковые проверки прав, скрытые циклы, неповторяемые retry и невозможность объяснить, почему действие было выполнено.
Automation должен быть общим rule engine поверх существующих системных контрактов:
EventBus публикует факты, которые запускают правила.
Workflow* предоставляет процессный контекст и разрешенные workflow-переходы.
Queue выполняет длительные, отложенные и повторяемые actions.
Security проверяет права запуска, просмотра, изменения и system principal.
Observability получает эксплуатационные сигналы о latency, ошибках, пропусках, циклах и очередях.
Доменные модули предоставляют только свои triggers, actions, payload resolvers и безопасные profiles.
Что Нужно Сделать
Нужно реализовать модель правил:
AutomationRule: stable key, title, description, scope, trigger, conditions, actions, priority, active flag, execution mode и owner.
Scope правила должен поддерживать систему, модуль, проект, workflow, record type, view, screen, host и event profile.
Правило должно иметь режимы enabled, disabled, dryrunonly и suspended.
Системные правила должны поставляться через JSON/system definitions и быть защищены от прямого редактирования.
Пользовательские правила должны создаваться как отдельные проектные записи или как управляемые копии системных правил.
Overrides системных правил должны храниться в AutomationProfile или проектных automation records, а не в ProfileManager. ProfileManager может хранить только пользовательские UIpreferences вокруг отображения и lastused настроек.
Нужно реализовать triggers:
Trigger должен ссылаться на зарегистрированный EventType, workflow-факт, Queue schedule или trigger provider доменного модуля.
EventBus является основным источником фактовтриггеров. Automation не владеет event log, outbox/inbox, delivery, retry или deadletter событий.
Trigger должен поддерживать фильтр по project, workflow, record type, status, field, host, actor и payload profile.
Один trigger может запускать несколько правил в определенном порядке.
Повтор события должен обрабатываться идемпотентно.
Trigger не должен раскрывать payload, недоступный правилу по правам и profile.
Нужно реализовать conditions:
Condition должен поддерживать проверку прав, workflow-статуса, значений полей, проекта, host, actor, record type, event payload и формата ИРБИС 128/64.
Condition должен иметь понятное диагностическое сообщение для администратора.
Ошибка condition должна обрабатываться по policy: остановить правило, пропустить правило или отправить в диагностику.
Conditions не должны выполнять изменяющие действия.
В первом промышленном контуре визуальный конструктор условий не обязателен. Достаточно структурированной формы параметров, выбора зарегистрированных predicates/formats, preview, dry-run и explain.
Нужно реализовать actions:
Action должен выбираться из зарегистрированного whitelist, поставляемого модулем-владельцем.
Нельзя вызывать произвольный PHPкод, произвольную __callфункцию, Action контроллера или shell-команду.
Workflow transition action должен выполняться через WorkflowTransition, а не прямым изменением статуса.
Command action должен вызывать зарегистрированную доменную automation command с проверкой прав и стандартным результатом выполнения.
Notification action должен публиковать событие или использовать профиль EventBus, а не отправлять сообщение напрямую.
Field update action должен быть ограничен разрешенными field keys, FieldConfiguration, правами и версией записи.
Длительные actions должны выполняться через Queue.
Для публичных и анонимных сценариев запрещены произвольные actions. Разрешены только явно whitelisted безопасные реакции на публичные события через system principal, Security, AbuseProtection и EventBus/Queue policy.
Нужно реализовать runtime:
Каждое выполнение правила должно создавать AutomationExecution с rule key, trigger id, event id, actor или system principal, trace id, idempotency key, started at, finished at, status, result и ссылками на затронутые объекты.
Выполнение должно поддерживать dry-run с предпросмотром actions без изменения данных.
Dry-run должен показывать matched rules, skipped conditions, planned actions, required permissions, Queue jobs, возможные workflow transitions и причины отказа.
Правило должно иметь idempotency scope и fingerprint входных данных.
Automation должен предотвращать бесконечные циклы через depth limit, cycle key, recursion policy и event causation chain.
Повтор выполнения должен быть доступен только для идемпотентных или явно безопасных actions.
Runtime должен фиксировать skipped, failed, queued, retried и completed states.
Синхронные blocking rules в первом промышленном контуре не поддерживаются. Blocking-логика остается в WorkflowTransition conditions, ФЛК/validators, Security и доменных проверках сохранения.
Нужно реализовать администрирование:
UI администратора должен позволять создавать, копировать, включать, выключать, переводить в dryrunonly и suspend правила.
UI должен показывать trigger, conditions, actions, execution mode, priority, scope, системность правила, where-used и последние execution results.
Администратор должен иметь возможность запустить dry-run для выбранного объекта или события.
Import/export JSON definitions должен поддерживать dry-run, проверку конфликтов ключей, проверку отсутствующих providers и защиту системных definitions.
Action registry должен показывать provider module, action key, title, description, параметры, required permissions, поддерживаемые scopes, sync/async режим и idempotency support.
Нужно реализовать интеграцию с HealthCheck:
HealthCheck должен находить отсутствующие EventType, trigger providers, action providers, workflow, transitions, fields, Queue handlers, permission keys и profiles.
HealthCheck должен выявлять конфликтующие keys, недоступные system definitions, неподдерживаемые action parameters, потенциальные циклы, disabled required dependencies и правила без прав выполнения.
HealthCheck должен иметь provider-проверки Automation без знания доменной логики Tasks.
Нужно реализовать интеграцию с Observability:
Automation должен публиковать signals о matched/skipped rules, condition errors, action failures, queue lag, retry, loop prevention, execution latency и dry-run usage.
Signals должны содержать safe payload, trace id, rule key, provider key, result и severity без раскрытия текста записи, скрытых полей, персональных данных и секретов.
Нужно реализовать контракт для Tasks как первого потребителя:
Tasks должен поставлять task-specific triggers, actions, payload resolver и безопасные системные rules.
Task triggers должны включать создание задачи, изменение значимого поля, добавление комментария, загрузку вложения, смену статуса, наступление срока, нарушение SLA и расписание.
Task actions могут включать назначение ответственного, изменение разрешенных fields, публикацию уведомления через EventBus, постановку задания в Queue, запуск разрешенного workflow-перехода и создание связанной задачи.
Tasks не должен хранить собственный automation engine и не должен напрямую выполнять rule runtime.
Правило Tasks не должно выполнять действие, которое пользователь или system principal не имеет права выполнить.
EventBus владеет событиями, outbox/inbox, delivery, retry и deadletter. Queue владеет job runtime. Security принимает решения доступа. Workflow* выполняет workflowпереходы. Доменные модули поставляют только безопасные trigger/action providers и payload resolvers.
Критерии Приемки
Администратор может создать правило trigger > conditions -> actions без написания PHPкода.
Правило можно включить, выключить, перевести в dryrunonly и suspended.
Trigger ссылается на зарегистрированный EventType, workflow-факт, Queue schedule или provider доменного модуля и не раскрывает payload сверх прав.
Condition выполняет только проверку и не меняет данные.
Action выбирается из whitelist и не может вызвать произвольный PHP-код или обойти Security.
Workflow transition action выполняется через WorkflowTransition.
Длительные actions ставятся в Queue и диагностируются как Queue jobs.
Dry-run показывает matched rules, skipped conditions, planned actions, required permissions, Queue jobs и причины отказа без изменения данных.
AutomationExecution фиксирует результат выполнения, trace id, actor/system principal, trigger context, idempotency key, ошибки и ссылки на затронутые объекты.
Защита от циклов предотвращает повторный самозапуск по causation chain, depth limit, cycle key и recursion policy.
Публичные и анонимные сценарии не могут напрямую запускать произвольные actions; допускаются только безопасные whitelisted reactions через system principal и policy.
Синхронные blocking rules не входят в первый промышленный контур Automation; блокировки сохранения и переходов остаются в WorkflowTransition, ФЛК/validators, Security и доменных проверках.
Tasks использует Automation как внешний системный rule engine и поставляет только task-specific triggers/actions/profiles.
Observability получает safe signals о выполнении правил, ошибках, пропусках, latency, queue lag, retry и loop prevention.
Проверки И Документация
Нужно подготовить TestA-сценарии для:
создания, копирования, включения, выключения и suspend правила;
trigger matching через EventBus;
проверки условий по правам, workflow-status, field predicate и формату;
запрета side effects внутри conditions;
whitelist actions и запрета произвольного вызова PHP;
workflow transition action через WorkflowTransition;
Queue execution для длительных actions;
dry-run без изменения данных;
idempotency и повторного события;
loop prevention;
публичного события с безопасной whitelisted reaction;
HealthCheck provider-проверок;
Observability signals;
system JSON import/export и защиты системных definitions;
task-specific scenario: событие задачи запускает правило, проверяет условия, планирует action и пишет AutomationExecution.
В Help должны быть подготовлены:
руководство администратора по настройке правил, triggers, conditions, actions, priorities, execution modes, dry-run и диагностике;
руководство разработчика по созданию trigger/action providers, payload resolvers, safe parameters, idempotency и TestA-сценариев;
эксплуатационный runbook по анализу failed/skipped executions, loop prevention, Queue retries, HealthCheck diagnostics и Observability dashboards.
-
PR по I1282820 добавляет первый контрактный срез общесистемного модуля Automation. В границах PR: правила AUTOMATIONRULE, системный JSON whitelist, dryrun, explainability, защита от циклов, HealthCheck-контракт, Help и TestA. Реальный запуск внешних действий не включен: Workflow, EventBus, Queue, Security, Observability и доменные модули остаются владельцами своих контрактов.
Куда смотреть:
В интерфейсе изменений не видно. Техническая точка: UseModule('Automation')~~>DryRunRule(...), UseModule('Automation')~~>ExplainRule(...), UseModule('Automation')~~>BuildExecutionPlan(...), modules/Automation/system/automation_definitions.json, TestA Automation.module.contract. Эффект: система получает ownerмодуль для nocode автоматизации, который строит explainable dry~~run план без побочных эффектов.
Сценарий в системе: АРМ Администратор > модуль Автоматизация -> список Правила автоматизации. Chrome: не подтверждено, локальный стенд не переключался на PRветку; загрузка модуля подтверждена через initsystem.php и TestA. Было: модуля Automation и типа записи AUTOMATIONRULE не было. Стало: после переключения на PR-ветку модуль доступен для администрирования правил Automation.
Help: подготовлен в modules/Automation/Help/Root.md, Purpose.md, AdminGuide.md, DeveloperGuide.md, Runbook.md; отдельные скриншоты не применимы, потому что PR добавляет системный контракт и не меняет существующий пользовательский экран.
Для PR-волны: ветка создана от текущего develop, head commit c54bc12f0832313bc97203d0e2db7d98d37ad7d6.
Изменения по файлам:
modules/Automation/api.php
Новый файл. Системный класс модуля Automation с PHPDoc для внешних функций.