NexTool Solutions

В GLPI встроенное согласование - это один раунд. Вы запрашиваете согласование у одного или нескольких человек, задаёте процент одобрения - и всё: нет иерархической цепочки, в которой финансовый отдел подключается только после того, как одобрил непосредственный руководитель. Модуль Approval Flow от NexTool закрывает именно этот пробел.

Проблема: иерархического согласования из коробки нет

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

Ядро предлагает единственный раунд согласования. Вы открываете вкладку согласований, выбираете согласующих (пользователей или группы) и задаёте поле validation_percent - процент одобрений, необходимый, чтобы заявка считалась согласованной. Все согласующие получают запрос одновременно. Нет порядка, нет условия «уровень 2 запускается, только если одобрил уровень 1», нет отдельного пути на случай отказа.

Почему эмуляция уровней через validation_percent не работает

При сопровождении чаще всего встречается попытка навязать последовательность через поле процента: команда запрашивает согласование у трёх человек и ставит 100%, полагая, что это превратится в цепочку. Не превратится. Все трое получают запрос одновременно - руководство видит его раньше, чем непосредственный руководитель успел взглянуть. Хуже того: если один отказывает, заявка переходит в REFUSED, но запросы остальных продолжают висеть в их очереди «мои согласования», засоряя представление каждого согласующего. И нельзя сказать «при отказе - эскалировать на другой уровень» или «при одобрении - автоматически закрыть с этим шаблоном решения». Обычно команда отказывается от встроенной функции и решает цепочку по e-mail, вне системы, - что убивает отслеживаемость и открывает брешь для аудита.

Как работает Approval Flow

Модуль Approval Flow добавляет многоуровневые процессы согласования, привязанные к категориям ITIL заявок, и использует встроенные шаблоны согласования самого GLPI (ITILValidationTemplate) - то есть согласующий по-прежнему работает со стандартной вкладкой согласований, без параллельного экрана.

• Один процесс на категорию ITIL - у каждой категории не более одного активного процесса, что устраняет неоднозначность в том, какое правило применяется к заявке.
• Уровни, связанные в дерево - у каждого уровня независимые пути для одобрения и отказа, поэтому для каждой ветви можно задать свой исход.
• Настраиваемое действие для каждого исхода - при одобрении или отказе вы выбираете, что происходит: ничего не делать, решить, закрыть или перейти на следующий уровень.
• Стандартизированное решение - когда действие - решить или закрыть, привязка к SolutionTemplate обязательна, что гарантирует одинаковое сообщение инициатору во всех заявках.
• Автоматический запуск - при создании заявки в категории с активным процессом согласование первого уровня запрашивается само, никому не нужно помнить об открытии вкладки согласований.
• Пользователи или группы на каждом уровне - каждый уровень может указывать на конкретного человека или на группу, используя те же цели, что и встроенный согласующий.

Диагностика: где читать состояние согласования

Прежде чем проектировать процесс, стоит понять, где GLPI хранит встроенное состояние, - именно его модуль оркестрирует под капотом. Два запроса решают задачу чтения:

-- GLPI: inspecionar o estado de validação nativo de um chamado.
-- global_validation e status seguem CommonITILValidation:
--   1 = NONE     (não sujeito a aprovação)
--   2 = WAITING  (aguardando)
--   3 = ACCEPTED (aprovado)
--   4 = REFUSED  (recusado)

SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;

-- Pedidos individuais: no nativo são todos "pares" na MESMA rodada.
-- Não existe coluna de "nível" nem ordem hierárquica.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;

Если вы уже пытаетесь имитировать уровни несколькими согласующими, второй запрос делает проблему очевидной: несколько строк в status = 2 (WAITING) одновременно, без единого столбца, выражающего порядок. Именно этот пробел закрывает цепочка уровней.

Как включить

1. Установите NexTool в ваш GLPI (10.0+ или 11.0+).
2. Перейдите в Настройки > NexTool > Модули.
3. Включите Approval Flow и нажмите Настроить.
4. На вкладке Процессы создайте процесс и свяжите его с нужной категорией ITIL.
5. Задайте уровни, согласующих (пользователь или группа) и действие для каждого исхода (одобрить/отклонить).
6. Для действий «решить» или «закрыть» привяжите соответствующий SolutionTemplate.

Кому подходит (и когда не использовать)

Это имеет смысл для организаций, которым нужно формальное управление в ИТ: запросы доступа, закупки, изменения инфраструктуры - любая заявка, требующая иерархической подписи с отслеживаемостью внутри самого GLPI. А также для команд, работающих по ITIL и не желающих, чтобы цепочка согласования жила в почтовом ящике.

Это не оправдано, если ваше согласование одноуровневое - в таком случае встроенного согласования GLPI достаточно, и цепочка уровней только добавит настройки без выигрыша. Модуль также не заменяет полноценный BPM-движок: его область - согласование заявок, а не оркестрация произвольных процессов с формами и внешними интеграциями.

Совместимость

• GLPI: 10.0+ и 11.0+
• План: PAID
• Плагин: NexTool 3.x+

Следующий шаг

Approval Flow входит в NexTool - экосистему модулей, расширяющую GLPI без доработки кода ядра. Свяжитесь с командой, чтобы увидеть многоуровневый процесс в работе в вашем сценарии.

Проверено командой NexTool Solutions.