---

[I128-2804] Доменные сущности, связи и классификация задач

---

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

---

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

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

Завершено: 07.09.2026 08:25

1. Цель Развить предметную модель Tasks так, чтобы задачи можно было использовать для сервисных, проектных, регламентных и пользовательских процессов: типы задач, шаблоны, чек-листы, связи, подзадачи, сервисы, компоненты, влияние, роли участников, компетенции, ограничения, импорт и экспорт.

2. Контекст Базовая запись TASK задает общий контракт хранения задачи, но промышленный модуль задач должен описывать предметные сущности, с которыми работает администратор и пользователь. Эти сущности должны оставаться taskspecific конфигурацией Tasks и не подменять общие механизмы ИРБИС 128. Связи между записями выполняются через стандартное поле 113 LINK. Права проверяет Security. Описание полей задается через FieldConfiguration. Поиск дублей выполняет FindDublet. Пользователи, организации, группы, компетенции и оргструктура используются через соответствующие системные модули и resolverы.

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

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

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

• Шаблон должен выбирать экран создания через WorkflowScreen или WorkflowScreenScheme, но не должен реализовывать собственный renderer формы.

• Поддержать простые чек-листы внутри задачи: текст пункта, признак выполнения, исполнитель, дата выполнения и ссылка на дочернюю задачу, если пункт превращен в отдельную задачу.

• Поддержать преобразование пункта чек-листа в дочернюю задачу через 113 LINK, если пункту нужны отдельные права, сроки, исполнитель, вложения, обсуждение, workflow или самостоятельный аудит.

• Поддержать typed-связи задачи с другой задачей, записью ЭК, заказом, читателем, пользователем, организацией, произвольной записью ИРБИС 128 и внешним URL.

• Для 113 LINK использовать единый принцип: тип связи хранится в 113^B, SID связанной записи - в 113^C; обратные пользовательские формулировки строятся по направлению связи и обратному поиску.

• Базовый набор типов связей должен покрывать: блокирует, зависит от, связана, дублирует, родительская задача, подзадача, источник, заявитель, затронутый объект.

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

• Проверять циклические блокировки и права пользователя на обе стороны связи при создании или изменении связи.

• Поддержать правила закрытия родительской задачи и задачи с блокерами через conditionформаты и taskspecific настройки проекта.

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

• Поддержать сервисы и компоненты как taskspecific каталоги или ссылки на внешние каталоги: ключ, название, владелец, ответственная группа, доступные типы задач, SLAbinding, активность и where-used.

• Поддержать матрицу влияния задачи на сервисы, базы данных, модули, host, организации и пользовательские группы. Уровень влияния должен участвовать в приоритизации, маршрутизации, SLA, уведомлениях и отчетности.

• Поддержать роли участников по модели RACI или аналогичной настраиваемой модели: ответственный, исполнитель, согласующий, информируемый, владелец сервиса, внутренний куратор и другие роли проекта.

• Tasks должен хранить task-specific роль и ссылку на пользователя, группу, подразделение или вычисляемый resolver, но не должен реализовывать общий Users/Organisations lifecycle.

• Поддержать компетенции и зоны ответственности как настройки маршрутизации задач: категории задач, компоненты, базы, модули, организации, языки, приоритеты или другие признаки выбора исполнителя.

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

• Поддержать проектные квоты и лимиты на создание задач, типы обращений, каналы, пользователя, роль, host или внешнюю интеграцию как task-specific policy. Общий механизм прав и защиты от злоупотреблений остается во внешних модулях.

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

• Поддержать экспорт списка задач в табличный формат и экспорт отдельной задачи в диагностический JSON с маскированием скрытых данных.

• Поддержать whereused для taskspecific типов, шаблонов, сервисов, компонентов, ролей и связей, чтобы администратор видел, какие задачи и настройки будут затронуты изменением или удалением.

• Подготовить task-specific Help по назначению каждой сущности, правилам настройки, совместимости и типовым ошибкам.

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

• Tasks владеет taskspecific типами, шаблонами, чеклистами, типами связей, сервисными и компонентными профилями, impact matrix, RACIролями, taskspecific competency bindings, квотами, импортом/экспортом задач и доменными правилами where-used.

• FieldConfiguration владеет общим registry полей, типами данных, storage binding, подсказками, вводом, отображением, поиском, экспортом и API-метаданными.

• FindDublet владеет профилями поиска дублей, normalizers, candidate resolvers, scoring, thresholds и диагностикой дублей.

• Users/Organisations владеют жизненным циклом пользователей, организаций, подразделений, групп, отсутствий, делегирований и общими resolver-ами участников.

• Security владеет проверкой прав на запись, связь, поле, view, импорт, экспорт, назначение и раскрытие скрытых данных.

• Workflow* владеет переходами, conditions, postfunctions и применением workflowправил.

• Collaboration, TaskPortal, NewsFeed, Menu, I128FMail, WorkflowBoard и WorkflowCalendar не входят в эту задачу; Tasks должен только оставить для них стабильные доменные ссылки и точки расширения.

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

• Администратор может настроить типы задач, типы обращений и шаблоны без знания физических полей записи TASK.

• Пользователь может создать задачу по шаблону, получить начальные значения, чек-лист, связи и корректный экран создания.

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

• Связи 113 LINK работают для задач, произвольных записей ИРБИС 128 и внешних URL; карточка показывает входящие и исходящие связи с учетом прав.

• Блокирующие связи и подзадачи могут влиять на доступность закрытия через condition-форматы без частной логики workflow engine в Tasks.

• Сервисы, компоненты и impact matrix влияют на маршрутизацию, приоритет, SLA-binding и отчетные признаки, но не дублируют внешние справочники.

• Роли участников, компетенции и зоны ответственности используются при назначении и проверке прав, но общий lifecycle пользователей и организаций остается во внешних модулях.

• Импорт имеет режим предварительной проверки, не обходит workflow и права, показывает созданные, обновленные, пропущенные и ошибочные записи.

• Экспорт и диагностический JSON не раскрывают скрытые поля и данные связанных объектов без права пользователя.

• Изменение или удаление taskspecific сущности показывает whereused и не оставляет битых ссылок в задачах.

  1. Проверки И Документация Нужно подготовить TestAсценарии для типов задач, шаблонов, чеклистов, преобразования пункта в подзадачу, связей 113 LINK, блокеров, дублей, сервисов, компонентов, impact matrix, ролей участников, компетенций, квот, import dryrun, export и whereused. Help должен объяснять администратору назначение каждой сущности, типовые настройки проекта и границы между Tasks и внешними системными модулями.

-

Реализован первый кодовый срез Tasks Core.

Что сделано:

• добавлен новый модуль Tasks и ObjectDataTask поверх обычной ObjectDataRecord;
• зафиксирована структура записи TASK: ключ 7^A, проект 7^B, заголовок/описание, классификация, сроки, участники, этап/версия/поставка;
• добавлены индексы TASK* через 1288 и использование стандартных индексов Workflow-состояния;
• состояние Workflow хранится через 113 LINK, история пишется через стандартный Workflow.AppendRecordHistory в 907;
• добавлены типизированные связи с задачами и произвольными записями, безопасные ссылки на FT/URL;
• добавлены редакторские переменные, Help и TestA safe-read проверка.

Границы:

• Tasks не реализует Workflow, Security, FT, FieldConfiguration или UI рабочего места; эти контракты остаются у owner-модулей.

Проверки:

• php -l modules/Tasks/api.php;
• php -l modules/Tasks/__call/Variables.inc;
• php -l modules/Tasks/Tests/Module.inc;
• TestA RunTarget Tasks/module/Module: 6/6 passed;
• TestA structural Tasks/__call/Variables: passed;
• git diff --check: без ошибок.

-

Стековый PR поверх #1302 / I128-2800, потому что базовый контракт записи Tasks еще не в develop. После merge #1302 ветку нужно будет перебазировать или retarget на develop.

Что сделано:

• добавлен системный Workflow JSON проекта TASK: workflow, статусы, переходы, screen/filter/view schemes, стартовые представления;
• добавлена поставка стандартных WS/WSS/MNU-файлов экранов Tasks через SetupModuleConfigure;
• добавлены Workflow-команды Tasks.NormalizeRecord и Tasks.SetClosedFlag;
• добавлены pft128-форматы колонок и карточки для WorkflowView;
• обновлены Help и TestA-проверки модуля Tasks.

Проверки:

• php l по новым __call, Workflowкомандам, форматам и Tests/Module.inc;
• json_decode modules/Tasks/workflow/tasks.json;
• git diff --check;
• TestA Tasks/Module safe-read: 9/9.

-

Реализован кодовый срез I128-2803: рабочее место задач и внутренний API модуля Tasks.

Что изменено:

• добавлены тонкие страницы Tasks для списков, создания и карточки задачи: Show, list, my, created, new, done, all, create, card;
• добавлены __call-функции Tasks для рендера страниц, получения списка/карточки, обновления полей, применения перехода и массового перехода;
• списки и карточка строятся через WorkflowView/WorkflowFilter, формы через WorkflowScreen/ws/he3, переходы через Workflow;
• обновлены canonical URL в колонках задач и системный JSON проекта TASK;
• добавлены Helpматериалы и TestAпроверки рабочего места.

Границы:

• Tasks не реализует собственный workflow-engine, фильтры, права, файловое хранилище или событийную шину;
• логика остается доменной: task-specific страницы, DTO, тексты, маршруты и безопасные обертки внутреннего API.

Проверки:

• PHP lint новых и измененных php/inc/page/pft128 файлов;
• tasks.json успешно разбирается как JSON;
• HTTP smoke: Tasks/list, Tasks/my, Tasks/create, Tasks/card отдают 200 без PHP-ошибок и без сообщения об отсутствующем WorkflowProject;
• TestA Tasks safe-read: 10/10;
• TestA Tasks safe-read structural: 36/36;
• git diff --check без ошибок, только стандартные предупреждения LF -> CRLF.

-

Реализован кодовый срез I128-2804 для модуля Tasks.

Что изменено:

• расширена доменная модель ObjectDataTask: тип обращения, сервис, компонент, уровень влияния, чек-листы, участники, impact refs и типизированные связи через стандартный 113 LINK;
• добавлены API GetTaskDomainModel и ApplyTaskTemplate;
• расширены системные JSON definitions Tasks: справочники, шаблоны, фильтры, колонки и секции карточки;
• обновлены ws/wss/mnu definitions экранов WorkflowScreen для доменной классификации;
• добавлены форматы карточки/колонки и Help по доменной модели;
• расширен TestA Tasks на новые поля, индексы, 113 LINK и шаблоны.

Границы:

• Tasks владеет только task-specific моделью и post/config contract;
• Workflow, WorkflowFilter, WorkflowScreen/View, Security, FieldConfiguration, FT, Users/Organisations и FindDublet остаются внешними owner-модулями.

Проверки:

• PHP lint измененных файлов;
• JSON parse modules/Tasks/workflow/tasks.json;
• TestA Tasks safe-read explicit: 12/12;
• TestA Tasks safe-read structural: 40/40;
• SetupModuleConfigure Tasks: ok;
• HTTP smoke: ?id=Tasks/list&project=TASK, ?id=Tasks/list&project=TASK&page=list&type=incident&service=platform, ?id=Tasks/card&project=TASK&key=TASK-1 returned 200 без Fatal/Warning/Notice.

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

1.1. 🔗 blocks: I128-2805

1.2. 🔗 blocks: I128-2810

1.3. 🔗 blocks: I128-2811

1.4. 🔗 blocks: I128-2838

1.5. 🔗 blocks: I128-2790

1.6. 🔗 blocks: I128-2797

1.7. 🔗 blocks: I128-2800

1.8. 🔗 blocks: I128-2813

1.9. 🔗 blocks: I128-2839

1.10. 🔗 blocks: I128-2823