---

[I128-2790] Расширить Workflow* для промышленного контура задач

---

НАЧАЛО >> Оглавление >> Общее описание >> История изменений >> Что нового в проекте I128 >> Версия 2026.3 >> [I128-2790] Расширить Workflow* для промышленного контура задач📄 Скачать в DOCX

---

Тип	Версия	Статус	Приоритет	Исполнитель
⚙️ Новые возможности	2026.3	🔘 Завершено	Средний	Ilya Mikhaylenko

Компоненты: Нет

Завершено: 09.09.2026 06:52

1. Цель Расширить универсальное семейство модулей Workflow* так, чтобы оно могло использоваться как промышленный механизм управления жизненным циклом любых record-based объектов ИРБИС 128, включая будущий модуль задач, но без знания их предметной структуры.

2. Контекст Workflow* должен быть системным слоем: проект workflow, сам workflow, статусы, переходы, условия, postfunctions, история переходов, черновики и публикация конфигурации должны работать одинаково для разных типов записей. Предметные модули поставляют только свои типы записей, настройки, postfunctions, форматы, тексты и доменные правила.

3. Что Нужно Сделать

• Зафиксировать модель WorkflowProject: проект, поддерживаемые типы записей, выбранный workflow для типа записи, начальный статус для legacyзаписей без workflowссылки, системные и пользовательские определения.

• Зафиксировать модель Workflow: набор статусов и переходов, версия конфигурации, draft/publish/rollback, запрет редактирования опубликованной системной конфигурации обычным администратором.

• Зафиксировать модель WorkflowStatus: стабильный ключ, русское название, статус для API, цвет/визуальное состояние, координаты на карте workflow, правила удаления и восстановления.

• Зафиксировать модель WorkflowTransition: исходный статус, целевой статус, название действия на кнопке, условие доступности, экран ввода, post-functions, режим выполнения и диагностируемый результат.

• Реализовать единый способ определения workflowсостояния записи через LINKполе 113: ссылка на проект workflow и текущий статус в этом проекте. Одна запись должна иметь возможность участвовать в нескольких workflow одновременно.

• Реализовать dryrun перехода: до выполнения пользователь или администратор должен видеть, будет ли переход доступен, какой статус получится, какие поля изменятся, какая запись истории 907 будет добавлена и какие postfunctions будут вызваны.

• Реализовать explainability доступности действия: если переход недоступен, система должна показать безопасную и понятную причину без раскрытия скрытых данных.

• Реализовать where-used и impact analysis для статусов, переходов, workflow и проектов, чтобы нельзя было опасно удалить используемую конфигурацию без диагностики последствий.

• Реализовать системные JSON definitions для поставляемых модулем workflow-проектов, workflow, статусов и переходов: setup/import должен добавлять новые системные записи, обновлять измененные и убирать записи, удаленные из developer config.

• Реализовать общий контракт postfunctions: GBLпостфункции выбираются из разрешенного меню, commandпостфункции вызываются через специальные __call/Workflowфункции модуля-владельца с типизированным контекстом и стандартным результатом.

• Историю успешных переходов писать в стандартное поле 907, а не через частные действия отдельных модулей.

  1. Границы Ответственности

• Workflow* не должен содержать частную логику Tasks, VirtualRef или других предметных модулей.

• Workflow* не должен знать физические номера полей предметной записи, кроме общесистемного LINK 113 и стандартной истории 907.

• Проверка прав должна выполняться через общий Security-контракт, а не через частные условия внутри Workflow*.

• Тяжелые, отложенные и повторяемые эффекты должны выноситься в Queue/EventBus через post-functions или обработчики владельцев, а не выполняться неявно внутри ядра workflow.

  1. Критерии Приемки

• Один и тот же workflow-механизм применим к разным типам записей без изменения кода Workflow*.

• Переход можно выполнить, предварительно проверить через dry-run и объяснить пользователю причину недоступности.

• Изменение workflow-конфигурации проходит через черновик, публикацию и возможность отката.

• Удаление используемого статуса, перехода или workflow блокируется или требует явного безопасного сценария с понятным impact report.

• Системные definitions воспроизводимо синхронизируются при setup/update и защищены от штатного редактирования, кроме специального режима разработчика.

• В записи после перехода корректно обновляется LINK 113 и появляется человекочитаемая история в поле 907.

  1. Проверки И Документация Нужно подготовить TestAсценарии для системных definitions, dryrun, выполнения перехода, недоступного перехода, записи 907, rollback конфигурации и защиты системных записей. В Help должны быть описаны модель workflowпроекта, статусы, переходы, postfunctions, публикация конфигурации и диагностика проблем.

-

1. Что сделано

• Добавлен explainable runtime для переходов Workflow: ExplainRecordTransition() возвращает allowed, diagnosticCode, checks/reasons, status diff, требуемый экран и план post-functions.

• Добавлен DryRunRecordTransition() для проверки перехода на копии записи без сохранения и без выполнения post-functions.

• Добавлен GetWorkflowImpactAnalysis() для базового whereused по проектам, статусам, переходам, экранам, схемам, фильтрам, представлениям и материализованным workflowсостояниям.

• Добавлены self-check методы HealthCheck_Self() для Workflow, WorkflowProject, WorkflowStatus, WorkflowTransition.

• WorkflowProject, WorkflowStatus, WorkflowTransition расширены административными описаниями; WorkflowStatus получил цвет для карты/UI со стандартным fallback по API-статусу.

• Импорт/синхронизация system JSON сохраняют description/color для проектов, статусов и переходов.

• Обновлены Helpразделы Workflow и добавлены TestA saferead сценарии для четырех Workflow*-модулей.

  1. Не входит в этот PR

• Перевод from/to статусов переходов с числовых кодов на ключи статусов: это требует отдельной миграции данных.

• Public ws renderer, WorkflowScreen drafts, WorkflowView pages и materialized WorkflowFilter: эти части остаются в отдельных задачах I128~~2791/I128~~2809.

• Draft/publish/rollback lifecycle проекта в полном объеме.

  1. Проверка

• php -l по измененным Workflow* API, __call и Tests/Module.inc: ok.

• git diff --check: ok.

• TestA explicit safe-read: Workflow 7/7, WorkflowProject 4/4, WorkflowStatus 4/4, WorkflowTransition 4/4.

• TestA structural safe-read: Workflow 51/51, WorkflowProject 13/13, WorkflowStatus 6/6, WorkflowTransition 6/6.

1. Связанные задачи

1.1. 🔗 blocks: I128-2791

1.2. 🔗 blocks: I128-2800

1.3. 🔗 blocks: I128-2801

1.4. 🔗 blocks: I128-2803

1.5. 🔗 blocks: I128-2804

1.6. 🔗 blocks: I128-2805

1.7. 🔗 blocks: I128-2809

1.8. 🔗 blocks: I128-2810

1.9. 🔗 blocks: I128-2820

1.10. 🔗 blocks: I128-2821

1.11. 🔗 blocks: I128-2822

1.12. 🔗 blocks: I128-2825

1.13. 🔗 blocks: I128-2831

1.14. 🔗 blocks: I128-2839

1.15. 🔗 blocks: I128-2840