Дублирующиеся заявки возникают из-за простой детали: когда кто-то нажимает «ответить всем» в переписке с поддержкой, сборщик почты GLPI не распознаёт сообщение как часть разговора и создаёт новую заявку. Модуль Mail Analyzer перехватывает такое сообщение до создания заявки и по заголовкам самого письма решает, является ли оно новой заявкой или лишь комментарием к исходной.
Проблема: встроенный сборщик теряет цепочку
Сборщик почты GLPI связывает ответ с исходной заявкой, читая метку, которую он сам вставляет в тему уведомлений, в формате [GLPI #0000123]. Пока эта метка сохраняется в ответе, всё работает: сообщение становится комментарием к нужной заявке. Проблема появляется, когда метка теряется.
Классический сценарий — «Ответить всем». Клиент создаёт заявку и ставит руководителя в копию. Поддержка отвечает, руководитель решает прокомментировать и нажимает «Ответить всем». Его почтовый клиент переписывает тему (RE:, ENC:, FW:), обрезает метку или начинает новое письмо на основе истории — и GLPI, не найдя [GLPI #...], создаёт вторую заявку по тому же разговору.
Результат знаком всем, кто работает в службе поддержки: две или больше заявок по одному вопросу, раздробленная история, риск того, что два аналитика будут параллельно работать, не зная друг о друге, и искажённый SLA, потому что каждый дубликат считается новым обращением. В корпоративных средах, где ставить руководителей в копию — часть культуры, это превращается в десятки дубликатов в неделю.
Как работает Mail Analyzer
Модуль работает через хуки жизненного цикла заявки, перехватывая уже собранное письмо до того, как оно станет заявкой. Вместо того чтобы полагаться только на метку в теме, он читает стандартные заголовки письма (RFC 5322) и применяет иерархическое решение по трём стратегиям:
- Анализ References — проверяет, ссылается ли письмо на
Message-ID, созданный самим GLPI (форматGLPI_*). Если да, это законный ответ на заявку, и он становится комментарием. - Анализ In-Reply-To — если
In-Reply-Toуказывает на письмо третьего лица, уже зарегистрированное модулем, а не наMessage-IDGLPI, сообщение определяется как цепочка копий и блокируется. - Проверка первого письма — запасной вариант: если у заявки ещё нет ни одного зарегистрированного письма, это сообщение считается исходным и пропускается.
Поверх этой основы три настройки управляют поведением в реальных средах:
- Thread-Index — улучшает обнаружение цепочек в средах Microsoft (Outlook/Exchange), которые используют этот собственный заголовок помимо
In-Reply-To. - Block Chain Emails — более агрессивный режим, который активно блокирует ответы третьих лиц из копии. Подходит для операций с большим объёмом, применять с осторожностью.
- Шаблон уведомления — когда письмо блокируется, отправитель получает настраиваемое уведомление с объяснением причины, что сохраняет прозрачность.
Заголовки, которые всё решают
На практике разница между комментарием и дубликатом заключается в двух строках заголовка. Пример ниже показывает оба случая рядом:
# Resposta legitima ao chamado: o cabecalho References cita o Message-ID do GLPI (GLPI_*)
# --> Mail Analyzer trata como ACOMPANHAMENTO do ticket original
Subject: [GLPI #0004521] Impressora do fiscal sem toner
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
# Terceiro em copia clicou "Responder a todos":
# In-Reply-To aponta para o e-mail de OUTRO usuario, nao para um Message-ID do GLPI
# --> Mail Analyzer BLOQUEIA a criacao de um ticket duplicado
Subject: RE: Impressora do fiscal sem toner
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>Возможности модуля и встроенное поведение
| Ситуация | Встроенный сборщик GLPI | С Mail Analyzer |
|---|---|---|
| Ответ сохраняет метку [GLPI #id] в теме | Становится комментарием к заявке | Становится комментарием к заявке |
| Третье лицо из копии отвечает «всем», и тема переписывается | Создаётся новая заявка (дубликат) | Распознаёт цепочку по References/In-Reply-To и не дублирует |
| Среда Exchange, группирующая по Thread-Index | Зависит только от темы и In-Reply-To | Также использует Thread-Index для сопоставления разговора |
| Письмо заблокировано как часть цепочки копий | Неприменимо | Отправитель получает настраиваемое уведомление |
| Первое письмо по новой теме | Создаёт заявку | Распознаёт как исходное и разрешает создание |
Как включить
- Установите плагин NexTool в GLPI и убедитесь, что сбор почты (приёмники) уже работает.
- Откройте Настройки > NexTool > Модули.
- Включите модуль Mail Analyzer.
- Настройте Thread-Index и Block Chain Emails в соответствии с профилем среды.
- Задайте шаблон уведомления для заблокированных писем.
Что мы узнали при сопровождении
При сопровождении сборщиков почты у клиентов ошибка, порождающая больше всего дубликатов, не техническая проблема GLPI, а поведенческая: руководитель в копии отвечает с телефона, приложение переписывает тему, и метка пропадает. До Mail Analyzer «исправлением» была просьба к людям не редактировать тему, что никогда не работает. Мы стали решать проблему у источника, читая References и In-Reply-To, которые почтовый клиент сохраняет, даже когда меняет тему. Деталь, которая видна только в эксплуатации: в средах Exchange включение Thread-Index даёт реальную разницу, потому что Outlook группирует разговор по этому заголовку и не всегда сохраняет чистый In-Reply-To. И практическая рекомендация: включайте Block Chain Emails постепенно и всегда с настроенным шаблоном уведомления, иначе законное письмо третьего лица блокируется молча, и никто этого не замечает, пока клиент не спросит.
Кому подходит (и когда не использовать)
Mail Analyzer подходит любой службе поддержки, которая создаёт заявки через сбор почты и работает в корпоративной среде, особенно:
- Компаниям, где руководителей и заинтересованных лиц регулярно ставят в копию в переписке с поддержкой;
- Операциям с высокой текучестью аналитиков, где дубликаты остаются незамеченными;
- MSP, обслуживающим нескольких клиентов и нуждающимся в упорядоченной истории по каждой компании;
- Командам, которым нужна консолидированная история для аудита и комплаенса.
Включать его нет смысла, если вы не используете сбор почты: если заявки поступают только через службу поддержки или через форму, перехватывать нечего. И стоит осторожно относиться к Block Chain Emails в небольших операциях, где дубликаты редки, потому что агрессивный режим может заблокировать письмо третьего лица, которое действительно должно было стать новой заявкой.
Совместимость
- GLPI: 10.x и 11.x
- План: FREE
- Плагин: NexTool 3.x или выше
- PHP: 8.0+
Mail Analyzer входит в NexTool — модульный плагин для GLPI. Чтобы увидеть модуль в вашем сценарии сбора почты, свяжитесь с командой.
Проверено командой NexTool Solutions.
