---

[I128-2810] Миграция VirtualRef в промышленный контур Tasks

---

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

---

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

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

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

1. Цель

Нужно подготовить промышленный переход от существующего модуля VirtualRef к универсальному модулю Tasks. Данные VirtualRef должны быть перенесены в модель задач так, чтобы пользователи и администраторы не потеряли вопросы, ответы, вложения, историю, статусы, публичную видимость, права и уже использованные ссылки.

1. Контекст

VirtualRef сейчас является отдельным пользовательским контуром виртуальной справки. После появления Tasks этот функционал должен перейти в общий taskmanagement слой, чтобы не поддерживать две параллельные системы обращений. Миграция должна быть управляемой: сначала dryrun без записи, затем проверяемый production cutover с freeze/read-only старого контура, отчетом расхождений и понятным планом отката.

Эта задача реализует только предметную миграцию VirtualRef в Tasks. Общие механизмы workflow, экранов, представлений, файлового хранилища, коммуникаций, событий, очередей, прав, диагностики и TestA используются как зависимости и не реализуются внутри этой задачи.

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

Нужно реализовать VirtualRefMigrationProfile. Профиль должен описывать сопоставление проектов, типов обращений, статусов, workflowсостояний, полей вопроса, заголовка, ответа, ссылок на источники информации, вложений, наблюдателей, ответственных, авторов, признаков FAQ, публичной видимости, прав и legacyключей.

Нужно реализовать dryrun без записи изменений. Dryrun должен читать существующие данные VirtualRef, строить план переноса, показывать количество переносимых записей, пропущенные записи, ошибки mapping, поврежденные вложения, неоднозначные права, неизвестные статусы и другие блокеры cutover. Отчет должен быть понятен администратору и пригоден для повторной проверки.

Нужно реализовать production cutover. Перед записью данных должен выполняться повторный dryrun, после чего старый VirtualRef переводится в режим freeze/readonly на время переключения. Новые записи Tasks должны получать штатные ключи TASK, а старые идентификаторы VirtualRef должны сохраняться как legacy-ключи или alias, чтобы старые публичные ссылки не ломались без явного правила redirect.

Нужно переносить workflow-состояние через штатный механизм 113 LINK, историю действий через стандартное поле 907, вложения через ссылки на FTObject, публичные ответы и комментарии через согласованный контракт Collaboration, а детальные изменения значимых полей через FieldHistory, если исходные данные позволяют восстановить old/new values.

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

Нужно реализовать сверку результата. После миграции администратор должен видеть совпадение счетчиков, списков, карточек, ключевых полей, статусов, FAQ-признаков, вложений, истории, прав, публичной видимости и поиска. Выборочная мигрированная задача должна открываться в новом списке и карточке Tasks.

Нужно определить режим старых страниц VirtualRef после cutover: readonly, redirect или compatibility view на Tasks по настройке проекта. Старые данные не должны изменяться скрыто после переключения, если выбран readonly.

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

В задачу входит только taskspecific логика миграции VirtualRef: профиль mapping, dryrun, production cutover, freeze/readonly, idempotency, сверка результата, legacyключи, audit миграции и Help/TestA-сценарии миграции.

В задачу не входит реализация общих модулей FT, TemporaryFiles, Collaboration, EventBus, Queue, FieldHistory, Security, Workflow*, WorkflowScreen, WorkflowView, WorkflowFilter, HealthCheck и TestA. Если нужного общего контракта не хватает, он должен быть оформлен как отдельная задача владельца соответствующего модуля, а не реализован частно внутри Tasks.

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

Dry-run запускается без записи изменений и показывает полный план миграции с ошибками, предупреждениями, счетчиками и примерами проблемных записей.

Production cutover переносит контрольный набор VirtualRef в Tasks без потери вопросов, заголовков, ответов, вложений, истории, статусов, workflowсостояний, FAQпризнаков, прав и публичной видимости.

Старые ключи VirtualRef сохраняются как legacyидентификаторы или alias. Уже опубликованные ссылки продолжают работать через явно выбранный readonly, redirect или compatibility режим.

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

Мигрированные записи открываются в списках и карточке Tasks, учитывают права Security и не раскрывают данные, которые были скрыты в VirtualRef.

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

1. Проверки И Документация

Должны быть подготовлены TestAсценарии на контрольном наборе VirtualRef: dryrun, успешный cutover, повторный запуск без дублей, поврежденное вложение, неизвестный статус, сохранение legacy-ключа, перенос истории, перенос FAQ и проверка прав.

Help должен содержать руководство администратора по подготовке mapping, запуску dryrun, анализу отчета, freeze/readonly, production cutover, сверке результата и rollback plan.

-

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

• Расширен ObjectDataTask полями SLA, пауз SLA, очереди, OLA-линий, таймеров, контрольных дат и результата ранжирования.

• Добавлены taskspecific __callфункции для объяснения SLA, расчета ранга и подготовки Queue-пересчета.

• Добавлены Workflow-команды Tasks: первый ответ, решение, пауза SLA, снятие паузы, взятие задачи из очереди, ручное повышение ранга.

• Системный проект Tasks расширен экраном SLA/очереди, фильтрами, колонками, секциями карточки и доменными справочниками SLA/OLA/queue/WIP/timer/ranking.

• Добавлены форматы представления, WS/WSS/MNU, Queue handler-ы и Help по SLA/очередям/ранжированию.

  1. Границы

Tasks хранит taskspecific правила, сохраненные результаты, поля, команды и payloadы. WorkCalendar, Queue runtime, EventBus, WorkflowFilter/View, Security и Observability остаются владельцами своих системных контрактов.

1. Проверки

• PHP lint измененных php/inc/pft128: OK, 24 файла.
• JSON parse modules/Tasks/workflow/tasks.json: OK.
• git diff --check: OK.
• Tasks::SetupModuleConfigure(): OK.
• TestA Tasks: total=13, passed=13, failed=0, skipped=0, blocked=0, warning=0.
• HTTP smoke: ?id=Tasks/List, My, New, Done, All, Create - HTTP 200 без PHP warning/fatal.

Target branch: feature/I128~~2804~~tasks~~domain~~entities-relations. Commit: 269dc31177bdb8222dc01291bfda43d3541e6dfd.

-

Задача: I128-2810

Что сделано:

• добавлен профиль миграции vref*to*task в системный JSON Tasks;
• добавлен DTO ObjectDataVirtualRefMigrationProfile и legacy-ссылки TASK в поле 17;
• добавлены API GetVirtualRefMigrationProfile, PlanVirtualRefMigration, ExecuteVirtualRefMigration;
• dryrun строит план без записи данных, ищет дубли по legacyмаркерам и возвращает blockers/warnings/counters;
• production cutover защищен условиями dryRun=false, confirm=cutover, sourceFrozen=true и повторной проверкой плана;
• при переносе создается TASK, сохраняются legacy markers, workflow-state 113, история 907 и snapshot вопроса/ответа;
• обновлены TestA и Help Tasks.

Границы:

• FT, Collaboration, FieldHistory, EventBus, Queue, Security, Workflow*, WorkflowScreen/View/Filter не реализуются внутри Tasks;
• вложения VirtualRef на этом срезе регистрируются как legacy attachment references до полноценного FT-переноса;
• статус источника читается через стандартный WorkflowProject/Workflow по проекту записи, без вызова доменной логики VirtualRef.

Проверки:

• PHP lint: OK;
• tasks.json JSON parse: OK;
• git diff --check: OK;
• Tasks::SetupModuleConfigure(): OK;
• TestA Tasks: total=56, passed=56;
• HTTP smoke Tasks/list, Tasks/my, Tasks/created, Tasks/new, Tasks/done, Tasks/all, Tasks/create: 200, без Fatal/Warning;
• live dry-run VirtualRef migration limit=5: ok=true, blocked=0.

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-2796

1.7. 🔗 blocks: I128-2797

1.8. 🔗 blocks: I128-2798

1.9. 🔗 blocks: I128-2799

1.10. 🔗 blocks: I128-2800

1.11. 🔗 blocks: I128-2801

1.12. 🔗 blocks: I128-2802

1.13. 🔗 blocks: I128-2803

1.14. 🔗 blocks: I128-2804

1.15. 🔗 blocks: I128-2806

1.16. 🔗 blocks: I128-2807

1.17. 🔗 blocks: I128-2809