---

[I128-2805] SLA, командные очереди и ранжирование задач

---

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

---

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

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

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

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

2. Контекст Задачи должны не просто храниться в системе, а управляемо исполняться по срокам, рабочему времени, приоритетам и командной нагрузке. Tasks должен хранить taskspecific SLAправила, результаты расчета, признаки очереди, доменные причины паузы, правила ранжирования и реакцию на нарушения. При этом общий календарь рабочего времени принадлежит WorkCalendar, фоновое выполнение - Queue, события и доставка - EventBus, trace id - TraceContext, фильтры и материализованные выборки - WorkflowFilter, права - Security, эксплуатационные метрики - Observability.

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

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

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

• Если SLA отключен для проекта или типа задачи, задача должна продолжать создаваться и проходить workflow без расчетов SLA.

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

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

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

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

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

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

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

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

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

• Очередь должна иметь ключ, название, проект, WorkflowFilter, участников, правила сортировки, правила взятия в работу, WIP-ограничения и режим выбора: любая доступная задача или следующая по приоритету.

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

• Взятие задачи из очереди должно выполняться через workflow-переход и фиксироваться в истории 907.

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

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

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

• Эскалация должна выполняться через EventBus и Queue, не отправляя уведомления напрямую из Tasks.

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

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

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

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

• Результат ранжирования должен быть доступен для сортировки списков, dashboard-счетчиков и командных очередей. Администратор должен видеть объяснение факторов, повлиявших на позицию задачи.

• Ручное повышение или закрепление позиции в очереди должно требовать отдельного права и фиксироваться в истории 907.

• Поддержать материализованные очереди, списки и dashboard-счетчики для тяжелых фильтров и часто используемых представлений. Пересчет выполняется через Queue инкрементально или по расписанию.

• Подготовить taskspecific providerпроверки для HealthCheck: наличие SLAправил, календарей, очередей, фильтров, таймеров, handlerов Queue, прав, форматов условий и корректных связей с проектом.

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

• Tasks владеет taskspecific SLAправилами, сохраненными результатами SLAрасчета, причинами паузы, OLAлиниями, командными очередями, WIPpolicy, правилами эскалации, taskspecific timer definitions, формулой ранжирования, доменными признаками просрочки и provider-проверками.

• WorkCalendar владеет общим календарем рабочего времени, сменами, праздниками, исключениями, timezone и API расчета рабочего времени.

• Queue владеет runtime фоновых заданий, scheduling, retry, timeout, backoff, dead-letter, worker management и ручным повтором.

• EventBus владеет event log, outbox/inbox, delivery, subscriptions, notification profiles, idempotency registry и dead-letter доставки.

• TraceContext владеет созданием, приемом, распространением и диагностикой trace id.

• WorkflowFilter/WorkflowView владеют универсальными фильтрами, materialized slices, списками, dashboard-блоками и представлениями.

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

• Observability, WorkflowBoard, WorkflowCalendar, Automation, BI и capacity planning не входят в эту задачу; Tasks должен только публиковать task-specific сигналы и данные, нужные этим будущим модулям.

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

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

• SLA можно включить и отключить на уровне проекта или типа задачи без поломки обычного workflow задачи.

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

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

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

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

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

• Эскалации, напоминания и отложенные действия выполняются через Queue/EventBus и повторно проверяют актуальность условий перед исполнением.

• Формула ранжирования дает сортируемый результат и человекочитаемое объяснение факторов.

• Ручное повышение позиции в очереди требует права и фиксируется в истории 907.

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

  1. Проверки И Документация Нужно подготовить TestAсценарии для включенного и отключенного SLA, расчета по рабочему календарю, праздникам и сменам, паузы SLA, пересчета через Queue, OLAпередачи, взятия задачи из очереди, запрета обхода очереди, WIPлимитов, эскалации, таймера, отложенного workflowдействия, ранжирования, ручного повышения, materializedсчетчиков и HealthCheck providerпроверок. Help должен описывать настройку SLA, очередей, пауз, OLA, WIP, эскалаций, таймеров и формулы ранжирования.

-

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

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

1.1. 🔗 blocks: I128-2811

1.2. 🔗 blocks: I128-2790

1.3. 🔗 blocks: I128-2793

1.4. 🔗 blocks: I128-2794

1.5. 🔗 blocks: I128-2795

1.6. 🔗 blocks: I128-2797

1.7. 🔗 blocks: I128-2800

1.8. 🔗 blocks: I128-2804

1.9. 🔗 blocks: I128-2817

1.10. 🔗 blocks: I128-2818

1.11. 🔗 blocks: I128-2821