---

[I128-2840] Реализовать WorkflowDesigner как единую административную студию настройки workflow-проектов

---

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

---

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

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

Завершено: 08.09.2026 13:52

1. Цель

Нужно реализовать модуль WorkflowDesigner как единую административную студию настройки workflow-проектов ИРБИС 128.

WorkflowDesigner должен позволить администратору настраивать промышленный процесс из одного интерфейса: проект, workflow, статусы, переходы, экраны, схемы экранов, фильтры, представления, доски, календари, согласования, автоматизацию, навигацию, публикацию, права и диагностику.

WorkflowDesigner не является новым workflow engine и не хранит source of truth для workflowсущностей. Он строит единую административную рабочую область, показывает связи между настройками и делегирует сохранение изменений модулямвладельцам.

1. Контекст

Настройка workflow-проекта в промышленной системе затрагивает несколько модулей: WorkflowProject, Workflow, WorkflowStatus, WorkflowTransition, WorkflowScreen, WorkflowView, WorkflowFilter, WorkflowApproval, WorkflowCalendar, Menu, Automation, Security, FieldConfiguration, HealthCheck, TestA и Help.

Если администратор вынужден переходить между разрозненными редакторами записей, он легко теряет общую картину процесса: какие статусы есть, какие переходы доступны, какой экран откроется, какие права проверяются, какие согласования включены, какие фильтры и страницы публикуют записи и почему конфигурацию нельзя публиковать.

WorkflowDesigner должен дать единый интерфейс "от и до", но не должен переносить в себя ответственность модулей-владельцев.

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

Нужно создать отдельный модуль WorkflowDesigner.

Первый промышленный срез должен включать:

• административную страницу Designer;

• выбор WorkflowProject и workflow;

• агрегированную model проекта, собранную через API модулей-владельцев;

• левое дерево сущностей проекта;

• центральную интерактивную схему процесса;

• правый inspector выбранной сущности;

• toolbar схемы;

• readonly и editable режимы по правам;

• переход к штатным редакторам owner modules;

• HealthCheck/dry-run diagnostics;

• Help и TestA coverage.

  1. Рабочая Область

Страница Designer должна быть рабочим административным интерфейсом, а не информационной страницей.

Интерфейс должен иметь четыре зоны:

• верхняя панель: выбор проекта, workflow, версии, режима, кнопки проверки, dry-run, публикации, экспорта, импорта и Help;
• левая панель: дерево проекта с группами Project, Workflow, Statuses, Transitions, Screens, Filters, Views, Boards, Calendars, Approvals, Automation, Navigation, Permissions, Diagnostics;
• центральная зона: визуальная схема со статусами и переходами;
• правая панель: inspector выбранного элемента.

Режимы первого среза:

• Обзор: просмотр полной модели проекта и связей.

• Проектирование: создание и изменение статусов и переходов через owner APIs.

• Экраны и страницы: просмотр связей transition -> screen, route -> view -> filter -> card/action.

• Права: объяснение итоговой доступности через Security.

• Проверка: HealthCheck, dryrun, whereused и impact analysis.

• Публикация: сравнение draft/published, publication dry-run и переход к публикации через WorkflowProject.

  1. Визуальная Схема

Схема должна показывать статусы как прямоугольники, переходы как направленные связи со стрелками.

Нужно поддержать:

• перемещение статусов мышью;
• автоматическое расширение холста при выносе узла за текущие границы;
• автоматическое уменьшение холста после уплотнения схемы без лишних скроллов;
• zoom in, zoom out, fit to screen, reset layout;
• выбор статуса или перехода кликом;
• открытие штатного редактора double click;
• добавление статуса;
• добавление перехода;
• редактирование выбранного элемента;
• удаление выбранного элемента через where-used/impact preflight;
• отображение service/loop transitions, которые не меняют статус;
• бейджи на переходах: screen, condition, post-functions, approval gate, automation hooks, rights warnings и diagnostics.

В обычном режиме узел статуса должен показывать человекочитаемое название без технического кода. Технические коды можно показывать в диагностическом режиме.

Цвет статуса должен браться из WorkflowStatus или API-статуса. WorkflowDesigner не должен хранить собственную независимую палитру.

1. Inspector

Inspector выбранной сущности должен показывать:

• тип сущности;
• owner module;
• stable key;
• название;
• system/readonly flags;
• changed state;
• last changed;
• where-used summary;
• итоговую доступность действий;
• проблемы конфигурации;
• быстрые действия;
• кнопку открытия полного штатного редактора.

Inline edit допускается только для безопасных часто используемых полей, если owner module предоставляет API изменения. Если такого API нет, WorkflowDesigner должен открывать штатный редактор записи.

WorkflowDesigner не должен напрямую менять физические поля чужих записей.

1. Делегирование Owner Modules

Все изменения конфигурации должны выполняться через owner modules:

• WorkflowProject владеет проектом, binding типов записей, draft/published состоянием, import/export/system JSON, publish и rollback.

• Workflow владеет runtime, состоянием записи, history 907, transition dry-run и impact analysis.

• WorkflowStatus владеет статусами и визуальными атрибутами статусов.

• WorkflowTransition владеет переходами, route, condition, post-functions, screenKey и approvalGateKey.

• WorkflowScreen и WorkflowScreenScheme владеют ws-экранами, draft/apply и public renderer.

• WorkflowView и WorkflowViewScheme владеют списками, карточками, routes, variants и page configuration.

• WorkflowFilter и WorkflowFilterScheme владеют фильтрами и materialized slices.

• WorkflowApproval владеет approval gates, policies, requests, decisions, delegation и continuation.

• WorkflowView владеет досочными типами представлений: kanban и timebox.

• WorkflowCalendar владеет календарными и timeline-представлениями.

• WorkflowNavigationScheme и Menu владеют навигацией и materialized menu records.

• Automation владеет no-code rules.

• Security владеет правами и explain access.

• FieldConfiguration владеет field keys и семантикой полей.

• HealthCheck владеет provider registry, result model и publication gate.

• TestA владеет тестовым каркасом.

• Help владеет опубликованной документацией.

  1. Project Lifecycle И Публикация

WorkflowDesigner должен различать сохранение черновых изменений и публикацию.

Перед публикацией нужно показывать:

• список изменений;
• deleted/disabled/changed entities;
• where-used;
• impact analysis;
• HealthCheck blockers/warnings/info;
• dry-run результата публикации;
• ссылку на проблемную сущность и owner module.

Публикация, rollback, import и export выполняются только через WorkflowProject и owner modules. Designer не должен самостоятельно переключать published flags или переписывать system JSON definitions.

1. Security

WorkflowDesigner не должен расширять права администратора.

Нужно проверять:

• право открыть Designer;
• право видеть проект;
• право видеть сущность;
• право редактировать сущность;
• право создавать статус или переход;
• право удалять сущность;
• право публиковать проект;
• право экспортировать или импортировать;
• право видеть diagnostics;
• право видеть скрытые поля или причины отказа.

Designer должен показывать причину отказа, если Security предоставляет explain API, но не должен раскрывать скрытые данные.

1. Extensibility

Нужно предусмотреть extension contract для модулей семейства Workflow* и смежных системных модулей.

Extension должен уметь добавить:

• группу в левое дерево;
• панель inspector;
• бейдж на статус или переход;
• быстрое действие toolbar/inspector;
• локальную проверку конфигурации;
• wizard создания своей сущности;
• ссылку на Help.

Добавление нового extension-модуля не должно требовать изменения ядра WorkflowDesigner, если extension соблюдает контракт.

1. Help И TestA

Нужно подготовить Help:

• руководство администратора по Designer;
• описание режимов работы;
• настройка процесса от проекта до публикации;
• работа с системными проектами и пользовательскими копиями;
• диагностика типовых ошибок;
• руководство программиста по extension contract.

Нужно подготовить TestA:

• загрузка Designer model на тестовом workflow-проекте;

• readonly mode;

• отказ доступа по Security;

• отсутствие extension-модуля с понятной диагностикой;

• создание статуса и перехода через owner APIs;

• сохранение координат статуса;

• where-used preflight при удалении;

• HealthCheck blocker перед публикацией;

• отсутствие прямой записи в чужие поля;

• структурная проверка metadata, Help и system JSON.

  1. Границы Реализации

Входит:

• отдельный модуль WorkflowDesigner;
• единая административная рабочая область;
• агрегированная Designer model;
• визуальная схема workflow;
• tree + inspector UX;
• безопасное создание и изменение статусов/переходов через owner APIs;
• переход к штатным редакторам owner modules;
• HealthCheck/dryrun/whereused отображение;
• extension contract;
• Help и TestA.

Не входит:

• новый workflow engine;

• собственное хранение WorkflowProject, Workflow, Status, Transition, Screen, View, Filter, Approval, Board, Calendar или Menu records;

• прямое изменение физических полей чужих записей;

• замена всех штатных редакторов;

• собственный редактор прав вместо Security;

• собственный renderer публичных форм, списков, досок или календарей;

• runtime approval, automation, events или queue jobs.

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

• Администратор может открыть Designer, выбрать workflow-проект и увидеть дерево проекта, схему процесса и inspector.

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

• Можно выбрать статус или переход кликом и открыть штатный редактор double click или кнопкой inspector.

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

• Перемещение статуса сохраняет layout через owner contract.

• Удаление выбранного статуса или перехода выполняет where-used/impact preflight и блокируется при blocker.

• Designer показывает screen, filter, view, approval, automation и navigation связи без переноса их source of truth в себя.

• Права на просмотр, изменение, удаление, публикацию и диагностику проверяются через Security.

• HealthCheck blockers/warnings/info отображаются в списке проблем и на связанных элементах схемы.

• Publication dry-run не применяет изменения, но показывает полный список blockers и warnings.

• System project доступен в readonly режиме; пользовательская копия создается через owner module.

• Отсутствующий extension-модуль отображается понятной диагностикой, а не PHP fatal error.

• Help содержит руководство администратора и программиста.

• TestA покрывает загрузку модели, Security refusal, readonly mode, создание статуса/перехода, where-used preflight и HealthCheck blocker.

-

Jira: https://jira.irbis128.ru/browse/I128-2840

Добавлен первый срез WorkflowDesigner как единой административной студии настройки workflow-проектов.

Входит в PR:

• модуль WorkflowDesigner со страницей выбора проекта и страницей дизайнера;
• агрегированная модель проекта: типы записей, Workflow, статусы, переходы, экраны, представления, фильтры, навигация, досочные и календарные представления;
• диагностика конфигурации рядом с названием без отдельной правой панели;
• переход к дизайнеру из редактора Workflow;
• Help и TestA-покрытие модуля.

Границы:

• WorkflowDesigner не становится runtime-engine;
• данные и правила остаются в Workflow*, WorkflowView, WorkflowScreen, WorkflowFilter, WorkflowProject и связанных модулях;
• отдельный WorkflowBoard не используется, доски являются типами представлений WorkflowView.

Проверки:

• PHP syntax check для измененных PHP/INC/PAGE файлов: ошибок нет;
• TestA safe-read targets по WorkflowDesigner, Workflow*, WorkflowView board scenario, Collaboration, WorkflowCalendar и Tasks: failed/blocked нет.

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

1.1. 🔗 blocks: I128-2790

1.2. 🔗 blocks: I128-2791

1.3. 🔗 blocks: I128-2793

1.4. 🔗 blocks: I128-2794

1.5. 🔗 blocks: I128-2795

1.6. 🔗 blocks: I128-2797

1.7. 🔗 blocks: I128-2798

1.8. 🔗 blocks: I128-2799

1.9. 🔗 blocks: I128-2809

1.10. 🔗 blocks: I128-2816

1.11. 🔗 blocks: I128-2818

1.12. 🔗 blocks: I128-2820

1.13. 🔗 blocks: I128-2821

1.14. 🔗 blocks: I128-2822

1.15. 🔗 blocks: I128-2825

1.16. 🔗 blocks: I128-2826

1.17. 🔗 blocks: I128-2828

1.18. 🔗 blocks: I128-2839