---

[I128-2801] Системный проект задач Tasks

---

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

---

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

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

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

1. Цель Поставить воспроизводимый системный проект задач, который после setup/update дает администратору рабочую базовую конфигурацию Tasks без ручного создания проекта, статусов, переходов, экранов, фильтров, представлений, прав и демонстрационных данных.

2. Контекст Модуль Tasks должен поставлять task-specific system JSON definitions, а общие механизмы их импорта, workflow, экранов, представлений, прав, проверки готовности и тестирования должны использоваться как внешние системные контракты. Системный проект нужен как эталонная конфигурация: его можно проверить, использовать для демонстрации и скопировать в пользовательский проект, но обычный администратор не должен напрямую редактировать поставляемые системные записи.

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

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

• Задать привязку типа записи TASK к базовому workflow проекта. Если у записи нет LINK 113 для проекта, должен использоваться начальный статус проекта без принудительной миграции записи.

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

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

• Для переходов с вводом данных указать screen key. Если экран не нужен, переход должен выполняться сразу после проверки доступности или подтверждения.

• Поставить базовые экраны Tasks: создание задачи, редактирование основных полей, изменение ответственного, уточнение, решение/закрытие, переоткрытие. Описание экранов должно использовать ws и task field pack.

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

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

• Поставить task-specific permission scheme references: кто может видеть проект, создавать задачу, видеть задачу, менять поля, выполнять переходы, назначать ответственного, видеть приватные секции и администрировать проект. Реализация проверок остается в Security.

• Поставить taskspecific providerпроверки для HealthCheck: наличие проекта, workflow, статусов, переходов, экранов, фильтров, представлений, прав, field pack, форматов, command handlers и корректных ссылок.

• Подготовить режим создания демонстрационного проекта и demoданных только по явному флагу администратора или в dev/testсценарии. Demo-данные должны быть помечены так, чтобы их можно было безопасно удалить.

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

• Повторный setup/update должен быть идемпотентным: добавлять новые системные definitions, обновлять измененные системные definitions по версии поставки и не затирать пользовательские копии проекта.

• Должна быть возможность создать пользовательскую копию системного проекта с новым ключом и названием. Копирование должно переносить task-specific настройки и связанные workflow/view/filter/screen references через штатные механизмы.

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

• Tasks владеет содержанием системного taskпроекта: какие статусы, переходы, экраны, фильтры, представления, taskspecific права, demoданные и providerпроверки нужны задачам.

• Tasks не реализует общий механизм system JSON sync, workflow engine, screen renderer, view renderer, Security, HealthCheck или TestA framework.

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

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

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

• После setup/update в системе существует валидный системный проект задач с базовым workflow, статусами, переходами, экранами, фильтрами, представлениями и task-specific настройками.

• Повторный setup не создает дубликаты и не затирает пользовательские копии проекта.

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

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

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

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

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

  1. Проверки И Документация Нужно подготовить TestAсценарии для первого setup, повторного setup, обновления system JSON, защиты системных записей, копирования проекта, HealthCheck providerпроверок, создания и удаления demoданных, открытия базовых фильтров/представлений и выполнения базового workflow. В Help нужно описать системный проект, состав поставки, создание пользовательской копии, demoрежим, самопроверку и типовые ошибки настройки.

-

Реализован первый кодовый срез 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.

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

1.1. 🔗 blocks: I128-2802

1.2. 🔗 blocks: I128-2803

1.3. 🔗 blocks: I128-2810

1.4. 🔗 blocks: I128-2811

1.5. 🔗 blocks: I128-2838

1.6. 🔗 blocks: I128-2790

1.7. 🔗 blocks: I128-2791

1.8. 🔗 blocks: I128-2797

1.9. 🔗 blocks: I128-2798

1.10. 🔗 blocks: I128-2799

1.11. 🔗 blocks: I128-2800