English · Русский
Плагин для GLPI 11, который заставляет заявку идти по регламенту: этап за этапом, в заданном порядке, через нужные подразделения — и не даёт закрыть её, пока регламент не пройден.
В GLPI есть задачи, дочерние заявки и согласования. Чего в ней нет — это порядка. Ничто не мешает технику закрыть заявку, минуя согласование ИБ; ничто не подскажет, что перед выдачей ноутбука сотрудника надо оформить в кадрах; и никакой штатный отчёт не ответит на вопрос «на каком этапе у нас застревают заявки и на сколько».
Типичный пример — выдача рабочего места новому сотруднику. Процесс проходит через пять отделов:
согласование бюджета → наличие на складе → оформление в кадрах
→ согласование доступов в СБ → настройка и установка ПО → выдача под акт
Без маршрута это либо одна заявка, в которой все шаги перечислены в описании и половина забывается, либо шесть отдельных заявок, которые никто не связывает между собой. С маршрутом это одна заявка, которая сама создаёт нужный объект в нужном отделе в нужный момент — и физически не даёт перескочить шаг.
Восемь этапов, пять подразделений. Колонки показывают, как одна заявка семь раз пересекает организационные границы. Пунктирный контур — необязательный этап, красная линия — единственный обратный переход.
Добавляет ровно одно, чего нет в штатной системе: управляемый переход между этапами и запрет действий вне текущего этапа.
Сроки, права, уведомления и отчётность остаются за GLPI. Собственных статусов заявки, собственных часов и собственной системы прав плагин не заводит — иначе сломались бы штатная отчётность и настройка жизненного цикла в профилях.
Ядро GLPI не правится, используются только штатные точки расширения.
Объект этапа — задача, дочерняя заявка или запрос на согласование — создаётся в момент входа в этап, а не все сразу при старте маршрута. Поэтому будущие этапы физически не существуют, и отметить их выполненными нечем. Это и есть основной способ соблюдения порядка, а не проверка в интерфейсе, которую можно обойти через API.
Маршрут и его этапы настраиваются в отдельном разделе администрирования. Таблица этапов показывает весь регламент одним экраном: порядок, режим исполнения, ответственных, организационную единицу, обязательность отчёта и реакцию на отказ согласующего.
На заявке появляется вкладка «Маршрут этапов»: состояние каждого этапа, созданный объект, кнопки управления и счётчик пройденных этапов в заголовке вкладки.
# распаковать в каталог плагинов GLPI
tar -xzf itilflow-1.6.0.tar.gz -C /var/www/glpi/plugins/
chown -R www-data:www-data /var/www/glpi/plugins/itilflow
# установить и включить
php /var/www/glpi/bin/console plugin:install itilflow --username=glpi
php /var/www/glpi/bin/console plugin:activate itilflowТо же можно сделать через интерфейс: Настройки → Плагины.
После установки появляются пять таблиц, два права в профилях и штатное автоматическое действие «Контроль сроков этапов». Проверить: Настройки → Автоматические действия — задача должна быть в списке со статусом «Запланировано».
Требования: GLPI 11.0.0 — 11.99.99. Проверено на 11.0.8. Ничего кроме самой GLPI не требуется — ни composer, ни npm, ни внешних сервисов.
Один режим на все случаи не работает: этап внутри отдела и этап, уходящий в другую организационную единицу, — принципиально разные вещи, потому что видимость заявки в GLPI даёт участие в ней, а не наличие задачи.
| Режим | Что создаётся | Когда применять | Как закрывается |
|---|---|---|---|
| Задача в заявке | задача с группой-исполнителем внутри той же заявки | маршрут целиком внутри одного отдела; самый дешёвый режим | исполнитель нажимает «Завершить этап» |
| Дочерняя заявка | отдельная заявка в целевой сущности со связью «дочерняя» | этап уходит в другой отдел; даёт этапу свой SLA и своё разграничение видимости | автоматически, когда дочернюю переводят в «Решена» |
| Согласование | штатный запрос на согласование GLPI со ступенью и порогом | утверждение руководителем, ИБ, владельцем системы, бюджетом | автоматически, по решению согласующего |
У этапа есть поле «Статус объекта на этапе»: когда этап берётся в работу, заявка получает выбранный статус. Без него заявка висит в исходном статусе всю дорогу, и по списку заявок не понять, на какой стадии процесс — согласование это, ожидание ответа или уже работа.
Список статусов берётся у типа объекта маршрута, поэтому для заявки, изменения и проблемы он свой. Завершающих статусов в списке нет: закрытие — дело всего маршрута, за него отвечает «Запрещать решение до прохождения маршрута».
Смена пишется в ленту строкой «Статус: Новая → Ожидание». По умолчанию стоит «Не менять» — маршруты, настроенные до 1.6.0, ведут себя как прежде.
Согласование не изобретается заново: в GLPI уже есть замещающие согласующие, коллективное согласование с порогом процентов, уведомления и отчёты. Плагин только создаёт запрос и ждёт результата.
У этапа-согласования есть поле «Кто согласует». По умолчанию согласующий задаётся при настройке этапа. Второе значение — «указывается при прохождении»: этап открывается и ждёт, пока исполнитель заявки или администратор процессов укажет конкретного человека и основание выбора.
Это нужно там, где согласующий определяется по обстоятельствам обращения и по источнику вне GLPI. Пример, из которого возможность и выросла: доступ к сетевой папке согласует её владелец, а реестр владельцев ресурсов ведётся отдельно от системы. Диспетчер смотрит реестр и указывает владельца — а система сохраняет, кто выбрал, кого и почему.
Маршрут при ожидании не считается остановленным. В ленте заявки появляется запись об ожидании, а после указания — запись с основанием. Лист согласования показывает и выбор, и обоснование: документ остаётся пригодным для аудита. Подменить согласующего после создания запроса нельзя.
Согласующих можно указать несколько, и каждый согласует отдельно: своим запросом, своим решением. Так собирается регламент вида «виза руководителя заявителя плюс виза владельца ресурса» — одним этапом, а не двумя. Итог этапа считается по его же полю «Порог согласования»: при 100% нужны все визы (после первой в ленте появляется «Ожидаем ещё N»), при 50% достаточно половины. Отказ отклоняет этап сразу, как только порог становится недостижим.
GLPI проверяет права и меняет данные на двух разных уровнях, и плагин перехватывает оба. Это не дублирование: проверка прав не вызывается при программном изменении объекта, поэтому одного уровня недостаточно.
| Уровень | Что делает | Что закрывает |
|---|---|---|
| Проверка прав | отзывает право на объекты чужого или неактивного этапа | форма заявки, Kanban, массовые действия, REST API — кнопка просто не показывается |
| Изменение объекта | отменяет операцию целиком | всё перечисленное плюс любые программные изменения; обойти нечем — внутри метода сохранения GLPI |
Включать запрет сразу на живом потоке нельзя: получите поток жалоб и не поймёте, где регламент расходится с практикой. Режим переключается на каждом маршруте отдельно.
| Режим | Поведение | Когда |
|---|---|---|
| Журнал | всё разрешено, нарушения записываются молча | первый месяц: соберёте реальную статистику отклонений |
| Предупреждение | действие проходит, фиксируется, исполнитель видит предупреждение | переходный период, пока команда привыкает |
| Запрет | операция отменяется с объяснением | когда процесс устоялся и все с ним согласны |
Отдельное право «Обход маршрута» снимает контроль для конкретного профиля — для дежурного диспетчера, который должен уметь разрулить затор. Действие всё равно попадает в журнал нарушений.
Маршрут запускается действием штатного бизнес-правила, а не отдельным механизмом плагина. Администратор настраивает старт теми же критериями, что и всё остальное в GLPI, и второго языка условий в системе не появляется.
- Условие: категория заявки равна вашей.
- Действие: «Запустить маршрут этапов» → назначить → ваш маршрут.
Если добавить форму каталога услуг и жёстко задать в её настройках категорию, инициатор не сможет ошибиться с выбором — цепочка замкнётся сама:
Маршрут можно запустить и вручную: на заявке вкладка «Маршрут этапов» → выбрать маршрут → «Запустить маршрут». Нужно право «Маршруты этапов».
Заявка в GLPI принадлежит ровно одной организационной единице. Поэтому межотдельный процесс — это не одна заявка, а дерево: родительская там, где инициатор, и по дочерней на каждый этап, уходящий в другую единицу.
Три стратегии выбора единицы для этапа:
- Сущность родительской — этап остаётся там же. Весь процесс внутри филиала.
- Заданная сущность — всегда в указанной. Централизованная служба: одна служба ИБ на весь холдинг.
- Сущность группы — вычисляется от группы-исполнителя. Исполнитель определяется правилом, а не жёстко.
Ловушка, о которой GLPI не предупреждает. Модель данных не запрещает назначить исполнителем группу чужой организационной единицы — такая запись создаётся без единой ошибки, фильтрует только выпадающий список в интерфейсе. В результате появляется заявка, назначенная на группу, которая её не видит, и она зависает навсегда. Плагин проверяет это сам: при несовпадении маршрут останавливается с понятным сообщением, а не создаёт «мёртвую» заявку.
Собственных часов плагин не заводит. У задачи в GLPI нет и не может быть своего SLA — это ограничение модели данных. Поэтому срок этапа делается штатным SLA дочерней заявки: обратный отсчёт на форме, рабочий календарь, эскалации, штатные отчёты по нарушениям сроков.
Отдельно у этапа есть поле «срок этапа, минут» — это не трудоёмкость, а дедлайн для отметки просрочки. Отсчёт по рабочему календарю маршрута. Просрочку отслеживает автоматическое действие: помечает шаг, пишет личный комментарий на заявку, кладёт запись в журнал. Срабатывает один раз и работу не блокирует — просроченный этап нормально закрывается.
Независимо от режима плагин записывает фактическую длительность каждого шага. Это то, чего в GLPI нет вообще, и ради чего затевается вся конструкция: отчёт «на каком этапе стоит процесс» и «сколько на самом деле занимает согласование ИБ».
Каждый переход между этапами пишется публичным комментарием в ленту заявки — инициатор следит за ходом, не обращаясь в поддержку:
Этап 1. Проверка наличия на складе — выполнен. Исполнитель: Смирнов Сергей. Что сделано: Ноутбук Lenovo T14, инв. 004977, зарезервирован.
Этап 2. Определение состава ПО — в работе. Ответственный: Служба поддержки L1. Пройдено этапов: 1 из 5.
Плюс упрощённая таблица этапов на вкладке в интерфейсе самообслуживания. Оба канала отключаются флагами маршрута независимо друг от друга — для процессов, детали которых заявителю не показывают.
- Передача этапа другому исполнителю с обязательной причиной. Задача переезжает вместе с этапом, прежний исполнитель теряет право её закрыть.
- Отзыв заявки инициатором с обязательной причиной, если маршрут это разрешает.
- Остановка и возобновление маршрута администратором процессов.
- Лист согласования — печатная сводка прохождения для разбора и аудита.
- Отчёт по узким местам — по этапам: прохождения, средняя, медиана, максимум, просрочки, возвраты, передачи.
Как читать отчёт: средняя длительность обманчива. Затор виден там, где максимум сильно больше медианы — большинство заявок проходит этап быстро, а часть застревает надолго, и разбирать надо именно эту часть. Много возвратов — плохо сформулированы требования к предыдущему этапу; много передач — неверно выбран ответственный.
Каждое сохранение маршрута увеличивает номер версии. Заявка запоминает версию на старте и доигрывает её до конца. Правьте регламент спокойно: заявки в работе не поменяют правила игры на ходу, а отчёты за прошлый квартал не перестанут сходиться.
Честный список того, чего плагин не делает.
- Параллельных этапов нет. Маршрут строго линейный: один активный этап в каждый момент. Возвраты на предыдущие этапы есть, ветвлений нет.
- Условных этапов нет. Пропустить этап можно вручную, если он помечен необязательным, но автоматического «пропустить, если сумма меньше N» нет.
- Полосы этапов в панели свойств заявки нет. Точки расширения для этой области в GLPI 11.0.8 объявлены, но при отрисовке формы заявки не вызываются. Весь интерфейс маршрута собран на вкладке заявки.
- Своих уведомлений плагин не шлёт. Работают штатные уведомления GLPI о задачах, дочерних заявках и согласованиях. О просрочке письмо не рассылается.
- Дочерние заявки поддерживаются для типа «Заявка». Для изменений и проблем доступны режимы «Задача» и «Согласование».
- Интерфейс только на русском языке. Строки вписаны в код, каталога переводов нет. Английской локализации на данный момент не существует.
Не заводит собственных статусов заявок, не считает своих часов вместо SLA и OLA, не строит свою систему прав вместо профилей и организационных единиц, не шлёт уведомления в обход штатных шаблонов и не прячет нарушения: всё, что заблокировано, видно в журнале и объяснено пользователю текстом, а не кодом ошибки.
Администрирование → Профили → [профиль] → Настройки
| Право | Кому давать | Что открывает |
|---|---|---|
| Маршруты этапов | администратор процессов, руководитель поддержки | создание и правка маршрутов и этапов, запуск вручную, прерывание и возобновление, журнал нарушений |
| Обход маршрута | диспетчер, дежурный администратор — выдавать осознанно | закрыть чужой этап и этап вне очереди в обход контроля |
Про право «Согласовать запрос / инцидент». Отдельного права согласующему
для работы маршрута не нужно. В GLPI 11 форма ответа на запрос гасится
по CommonITILValidation::canAnswer(), а он смотрит только на то, назначен ли
пользователь согласующим, и права профиля не учитывает. Само право фильтрует
другое — кого предлагать в штатном выборе согласующего (dropdownValidator),
а плагин назначает согласующего программно и этот выбор не использует.
Проверено на GLPI 11.0.8: пользователь со штатным профилем Technician, у которого флагов согласования нет, успешно ответил на запрос, и маршрут перешёл на следующий этап. До версии 1.3.2 плагин выдавал на такой настройке предупреждение — оно было ложным и удалено.
- Обучающий документ — как собрать маршрут с нуля на разборе живого процесса. Начните отсюда.
- Руководство администратора и исполнителя — полный справочник всех полей и режимов, 17 страниц. Составлено для 1.3.1: раздел про право «Согласовать запрос / инцидент» устарел, актуальное описание — выше в разделе «Права в профилях».
- История изменений
GNU General Public License версии 3 или более поздней. Полный текст — в файле LICENSE.
Copyright (C) 2026 itilflow contributors
Программа распространяется в надежде, что окажется полезной, но без каких-либо гарантий.