Согласование заявок по электронной почте без входа в GLPI

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

В этой статьеРазделов: 9

Просить руководителя войти в GLPI только ради согласования заявки — это трение, которое стоит часов SLA. Те, кто работает в службе поддержки, знают эту картину: письмо о согласовании приходит, руководитель читает его на телефоне, пароля под рукой нет, и заявка спит, пока кто-нибудь не напомнит по телефону.

Проблема

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

Результат предсказуем: зависшие согласования, заявки, ожидающие ответа, который так и не приходит, и команда, тратящая время на ручные напоминания. Опрос удовлетворённости — крайний случай: доля ответов близка к нулю, когда требуется вход, потому что пользователь просто бросает всё на экране аутентификации. Дело не в нежелании отвечать, а в лишнем шаге, который никто не хочет преодолевать.

Как это работает

Модуль Mail Interactions из NexTool добавляет в GLPI теги уведомлений. В момент постановки письма в очередь модуль заменяет каждый тег уникальным временным URL. Получатель кликает, попадает на публичную страницу, подтверждает действие, и GLPI обновляется — без экрана входа.

  • Согласовать или отклонить — теги ##ticket.approve_link## и ##ticket.reject_link## добавляются в шаблон уведомления о согласовании. Согласующий открывает ссылку, при желании пишет обоснование и подтверждает.
  • Подтвердить или отклонить решение — ##ticket.validate_link## закрывает заявку, когда инициатор подтверждает, что проблема решена; ##ticket.reopen_link## открывает её снова для повторной обработки.
  • Опрос удовлетворённости в один клик — ##ticket.satisfaction_link_1## … ##ticket.satisfaction_link_10## уже содержат предвыбранную оценку; пользователь кликает по оценке прямо в письме и, если хочет, оставляет комментарий.
  • Заявки, изменения и проблемы — те же теги есть для каждого типа объекта: ##ticket.*##, ##change.*## и ##problem.*## (для проблемы — только подтвердить и открыть повторно).
  • Одноразовые токены со сроком действия — каждая ссылка действует настраиваемый период (по умолчанию 7 дней; для опроса удовлетворённости — длительность опроса организации) и аннулируется при первом подтверждении, что исключает повторные клики и повторное использование.
  • Обязательное обоснование, когда это имеет смысл — можно требовать комментарий при отклонении, повторном открытии или при оценках удовлетворённости на уровне порога или ниже, повышая качество записи.

Модуль и штатный GLPI

Что меняется на практике по сравнению со стандартным поведением GLPI:

ДействиеШтатный GLPIС Mail Interactions
Согласовать / отклонитьСогласующему нужно войти в систему и открыть заявкуОдин клик по ссылке в письме, подтверждение на публичной странице
Подтвердить / отклонить решениеИнициатор действует внутри аутентифицированного интерфейсаПрямая ссылка в письме о предложенном решении
Опрос удовлетворённостиОтвет в интерфейсе или на портале GLPIПредвыбранная оценка, ответ в один клик
Пользователь без учётной записи в GLPIНе может действоватьТоже не может: ссылка генерируется только для адреса, зарегистрированного у пользователя GLPI
Безопасность ссылкиАутентифицированная сессия GLPI256-битный токен, одноразовый, со сроком действия и HTTPS

Реальный пример: теги в шаблоне уведомления

Теги добавляются в HTML-тело шаблона уведомления о согласовании (Настройки > Уведомления > Шаблоны уведомлений). Типичный фрагмент тела:

<!-- Template: "Ticket validation" event -->
<p>Hello ##validation.validator##,</p>
<p>Ticket <strong>##ticket.title##</strong> (##ticket.id##)
   is awaiting your approval.</p>

<p style="text-align:center">
  <a href="##ticket.approve_link##"
     style="background:#22c55e;color:#fff;padding:12px 20px;border-radius:6px">
     Approve
  </a>
  <a href="##ticket.reject_link##"
     style="background:#ef4444;color:#fff;padding:12px 20px;border-radius:6px">
     Reject
  </a>
</p>

<p>The links expire in 7 days and can be used only once.</p>

При формировании письма Mail Interactions заменяет каждый тег URL с токеном. Исключительно для иллюстрации формат выглядит так:

https://support.yourcompany.com/plugins/nextool/ajax/module_ajax.php
    ?module=mailinteractions&file=approve.php
    &token=Yc7d...opaque-256-bit-token...&a=approve

Токен ничего не кодирует о заявке: это случайное значение, которое существует только потому, что было выпущено и сохранено на сервере. Его невозможно подделать, угадать или использовать повторно. Основные настройки находятся на вкладке «Настроить» модуля:

# Setup > NexTool > Modules > Mail Interactions > Configure
token_ttl_days                     = 7    # link lifetime, in days
force_https_links                  = 1    # always generate https:// URLs
require_reject_description         = 1    # require a justification on reject
require_reopen_description         = 1    # require a justification on reopen
satisfaction_max_stars             = 5    # survey scale (1 to 10 stars; default 5)
satisfaction_require_comment_below = 3    # example: require a comment if score <= 3 (default 0 = never)

Что мы узнали при сопровождении

Обслуживая GLPI клиентов, мы чаще всего видим ошибку не техническую, а конфигурационную: теги согласования помещают не в тот шаблон уведомления. Если вставить ##ticket.approve_link## в шаблон, который срабатывает и на другие события (например, «Заявка обновлена»), ссылка попадёт в письма, где нет ожидающего согласования, — и получатель получит ссылку, ведущую лишь на страницу ошибки. Правильно использовать эти теги только в шаблоне события согласования. Это просто, но на это приходится значительная часть открываемых нами заявок в поддержку вида «ссылка не работает».

Второй урок пришёл из инфраструктурной детали. Почтовые шлюзы безопасности — Microsoft Safe Links, Mimecast и аналогичные — заранее открывают ссылки в сообщениях, чтобы просканировать их до клика пользователя. Если бы согласование выполнялось по простому GET-запросу ссылки, эти роботы сами «согласовывали» бы заявку, порождая фантомные согласования. Поэтому модуль никогда не действует по клику: ссылка открывает страницу подтверждения, а действие записывается только в POST с собственным токеном формы. Робот, выполняющий предварительную загрузку, видит страницу, но не подтверждает форму, поэтому одноразовый токен остаётся нетронутым. Именно это архитектурное решение предотвратило ложные согласования у клиента с корпоративным Office 365 — проблема, которая проявляется только в продуктиве и никогда в тестовой среде.

Тонкая деталь, которую стоит включить: при подтверждении решения, если в организации настроен срок закрытия (solvedelay в GLPI), модуль использует этот срок как срок действия ссылки вместо стандартных 7 дней. Так ссылка живёт ровно столько, сколько заявку ещё можно открыть повторно, — ни больше, ни меньше.

Как включить

  1. Убедитесь, что плагин NexTool установлен в вашем GLPI 11.
  2. Откройте Настройки > NexTool > Модули.
  3. Активируйте Mail Interactions и нажмите Настроить, чтобы задать срок действия токена, принудительный HTTPS и правила обоснования.
  4. В разделе Настройки > Уведомления > Шаблоны уведомлений отредактируйте шаблон события согласования (или решения/удовлетворённости) и добавьте нужные теги в тело.
  5. Запустите тестовое согласование и проверьте письмо: ссылки должны вести на /plugins/nextool/ajax/module_ajax.php с токеном в URL.

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

Mail Interactions подходит любой организации, которая использует процессы согласования в GLPI и страдает от задержек, потому что согласующие редко заходят в систему. Он особенно ценен для служб поддержки, обслуживающих конечных пользователей и внешних клиентов, которые редко открывают GLPI, — они подтверждают решения и отвечают на опросы без каких-либо барьеров доступа.

Когда не использовать: если ваша политика безопасности требует, чтобы каждое согласование отслеживалось через аутентифицированный вход и MFA (финансовый комплаенс, согласования на крупные суммы), публичная страница не заменяет этот контроль — в таком случае оставьте согласование внутри аутентифицированной сессии GLPI. Модуль снимает трение, но не заменяет электронную подпись, имеющую юридическую силу.

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

  • GLPI: 11
  • Плагин: NexTool (модуль Mail Interactions, базовая версия 6.9.1 или выше)
  • Поддерживаемые объекты: заявка, изменение и проблема (для проблемы — только подтвердить/открыть повторно)
  • План: лицензируемый

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

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


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

Часто задаваемые вопросы

Да. Каждая ссылка содержит случайный 256-битный токен, сгенерированный на сервере, сохранённый в базе данных и действительный для одного-единственного действия. Он истекает (по умолчанию через 7 дней), передаётся только по HTTPS, когда эта опция включена, а согласование записывается только тогда, когда человек подтверждает его на странице, — никогда по простому клику.

Нет. Клик по ссылке лишь открывает страницу подтверждения (GET); действие применяется только в POST с собственным токеном формы. Роботы предварительного просмотра, такие как Microsoft Safe Links и Mimecast, видят страницу, но не подтверждают форму, поэтому одноразовый токен остаётся нетронутым.

Пользователь в GLPI нужен, но входить в систему не требуется. Ссылка генерируется, только если адрес получателя принадлежит пользователю GLPI; в противном случае она ведёт на страницу ошибки. Действие выполняется на публичной странице, без аутентификации.

Нет. Модуль распространяется только для GLPI 11. Помимо заявок (Ticket), теги охватывают изменения (Change) и проблемы (Problem, с подтверждением/повторным открытием), через ##change.*## и ##problem.*##.

В течение срока, заданного в token_ttl_days (по умолчанию 7 дней). При подтверждении решения, если у организации задан срок закрытия (solvedelay), модуль использует этот срок как срок действия ссылки, чтобы она жила ровно столько, сколько заявку ещё можно открыть повторно. В опросе удовлетворённости действует длительность опроса, заданная в организации.

Да. Опции require_reject_description и require_reopen_description делают комментарий обязательным. В опросе удовлетворённости satisfaction_require_comment_below требует комментарий, когда оценка равна заданному порогу или ниже его.

Нужна помощь?