Некоторые процессы всегда порождают производную заявку, и каждый раз, когда этот шаг забывают, процесс тихо проваливается. Модуль Ticket Flow от NexTool превращает эту цепочку в автоматизацию: когда заявка удовлетворяет критерию, он создаёт следующую заявку из встроенного шаблона GLPI без участия человека.
Проблема
Многие категории заявок всегда следуют одному и тому же сценарию. Когда создаётся заявка «Заказ услуги», автоматически должна появиться заявка «Финансовое согласование». Когда заявка «Обслуживание» решена, должен появиться «Опрос о качестве». В стандартном GLPI эта оркестрация держится на памяти специалиста — если он вспомнит. Результат известен: пропущенные шаги, незавершённые процессы и невозможный аудит, потому что нет записи о подпроцессах, которые должны были быть открыты.
Стоит честно сказать, что GLPI уже умеет. Бизнес-правила для заявок (RuleTicket) отлично подходят для маршрутизации, назначения и категоризации, но они действуют на ту самую заявку, которая создаётся или обновляется. Ни одно встроенное правило не создаёт новую заявку из другой. Именно этот пробел и закрывает Ticket Flow.
Как работает Ticket Flow
Модуль позволяет настраивать потоки, которые запускают создание новой заявки, когда исходная заявка удовлетворяет критерию. Каждый поток привязан к категории ITIL и событию-триггеру и использует встроенные шаблоны заявок GLPI для создания производной заявки:
- 3 настраиваемых триггера — заявка создана, заявка решена и заявка закрыта. У категории может быть несколько потоков, в том числе на одном триггере, которые выполняются в порядке, заданном в каждом из них.
- Интеграция с TicketTemplate — дочерняя заявка создаётся из встроенного шаблона GLPI и наследует категорию, заголовок, описание, группы и приоритет, уже настроенные в шаблоне.
- Движок на встроенных хуках — выполнение происходит автоматически через хуки item_add и item_update объекта Ticket, без зависимости от cron или ручных действий.
- Защита от зацикливания — внутренний механизм не позволяет созданной заявке запустить другой поток в рамках той же операции, исключая риск бесконечной рекурсии.
- Журнал выполнения — каждое срабатывание фиксируется со ссылками на исходную и созданную заявки, что обеспечивает полную прослеживаемость.
- Вкладка теста — можно создать тестовую заявку из шаблона прямо на экране настройки, прежде чем выпускать поток в продакшен. Внимание: тест создаёт реальную заявку и требует отдельного права.
Почему шаблон заявки — сердце потока
Поскольку дочерняя заявка создаётся из TicketTemplate, качество потока целиком зависит от того, как заполнен шаблон. Прежде чем запускать поток в продакшен, стоит проверить предопределённые поля ваших шаблонов. Запрос ниже выводит шаблоны заявок и их предопределённые поля — если поле группы или ответственного пустое, дочерняя заявка рождается «сиротой»:
-- Modelos de chamado e seus campos predefinidos.
-- O Ticket Flow copia esses valores no chamado filho.
-- Campo essencial em branco (grupo/responsavel) = filho orfao.
SELECT tt.id AS modelo_id,
tt.name AS modelo,
tp.num AS campo_num,
tp.value AS valor_predefinido
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;Каждая строка — предопределённое поле шаблона. Значение num — это опция поиска GLPI (заголовок, категория, группа инициатора, назначенная группа, приоритет). Шаблон без назначенной группы порождает дочернюю заявку, которую никто не видит в очереди, и процесс застревает ровно там, где должен был двигаться дальше.
Ticket Flow и встроенные возможности GLPI
| Потребность | Встроенная возможность GLPI | Ticket Flow |
|---|---|---|
| Автоматически создать производную заявку | Нет — бизнес-правила редактируют только саму заявку | Да, по категории + триггеру |
| Повторно использовать предустановки полей | TicketTemplate, применяемый вручную при создании | TicketTemplate, автоматически применяемый к дочерней |
| Запуск по решению или закрытию | Нет триггера для создания другой заявки | Триггеры: создана, решена, закрыта |
| Избежать цикла создания | Неприменимо | Встроенная защита от рекурсии |
| Отследить связь родительской и дочерней | Разрозненная история в заявке | Журнал со ссылкой от родительской заявки к дочерней |
Как включить
- Установите плагин NexTool в ваш GLPI.
- Откройте Настройки > NexTool > Модули.
- Включите Ticket Flow и нажмите «Настроить».
- На вкладке Потоки создайте поток, выбрав категорию, триггер и шаблон дочерней заявки.
- Проверьте шаблон на вкладке теста, прежде чем делать поток активным: отдельного переключателя для движка нет, и при включённом модуле каждый активный поток уже работает.
Кому подходит — и когда не использовать
Ticket Flow предназначен для команд со структурированными процессами, в которых создание одной заявки — условие начала другой: управление изменениями, найм, проекты и процессы контроля качества, где пропущенный шаг реально влияет на работу и аудит.
Это не тот инструмент, если вам нужно выстроить цепочку задач внутри одной заявки (для этого есть поток подзадач) или если логика сводится к назначению или категоризации самой заявки — с этим справляются встроенные бизнес-правила. Ценность Ticket Flow проявляется именно тогда, когда процесс должен породить другую заявку со своим владельцем и сроком.
Чему мы научились, сопровождая это
При сопровождении ошибка номер один в Ticket Flow никогда не бывает в движке: она в шаблоне дочерней заявки без назначенной группы — дочерняя заявка рождается без владельца и исчезает из очереди. Второй было старое правило «один активный поток на категорию», из-за которого два процесса одной категории боролись за одно место; начиная с версии 2.0 категория принимает несколько потоков, выполняемых в порядке, заданном в каждом из них. Третья — самая коварная: триггер «закрыта» срабатывает и тогда, когда GLPI закрывает заявку сам, через процедуру автоматического закрытия по неактивности (cron autoclose). Мы видели, как клиент утром обнаружил пачку дочерних заявок, созданных ночью, потому что процедура закрыла партию старых заявок и каждое закрытие запустило поток. Рекомендация, которую мы стандартизировали: оставляйте триггер «закрыта» для процессов, которые действительно должны выполняться при закрытии, выбирайте «решена», когда цель — реагировать на решение, и всегда проверяйте дочерний шаблон на вкладке теста перед включением потока.
Совместимость
- GLPI: 11
- План: PAID
- Плагин: база NexTool 6.11.0 или выше
Ticket Flow входит в NexTool — экосистему модулей для расширения GLPI без доработки кода. Свяжитесь с командой, чтобы получить демонстрацию.
Проверено командой NexTool Solutions.
