Listener ScriptRunner без рекурсии: синхронизация поля по событию

Сценарий обновления зависимого признака

При изменении категории сервиса Jira должна обновлять поле маршрутизации, которое использует команда поддержки. Listener подходит для реакции на событие, но общий обработчик любого обновления легко начинает реагировать на собственные изменения. В журнале появляется цепочка событий, пользователи получают лишние уведомления, а соседние правила усиливают цикл. Защита начинается с точного описания входного события и целевого изменения.

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

Фильтр события и области

В настройках listener выберите необходимое событие и ограничьте проекты. Внутри логики дополнительно проверяйте тип задачи и интересующее изменение. Не используйте событие обновления как повод пересчитывать всё содержимое Jira. Если выбранный контекст предоставляет сведения об изменённых полях, используйте документированный для установленной версии способ их проверки. При отсутствии ожидаемых данных безопаснее завершить обработку с понятной диагностикой, чем предположить изменение категории.

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

Сравнение перед записью

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

Изменяйте поля через поддерживаемые Jira и ScriptRunner механизмы, учитывая права, индексацию и отправку событий. Не подавляйте все события только ради разрыва цикла, пока не проверили зависимые интеграции: они могут перестать узнавать о корректном изменении. Если требуется специальная политика уведомлений, документируйте её отдельно. Прямые записи в базу ради скорости обходят важные механизмы и усложняют восстановление.

Проверьте цепочки автоматизаций

Нарисуйте граф: изменение категории запускает listener, изменение маршрута запускает правило назначения, назначение может создавать новое событие. У каждого обработчика запишите изменяемые поля. Цикл часто находится не внутри одного скрипта, а между двумя независимыми конфигурациями. На тестовом проекте включайте компоненты последовательно и наблюдайте количество событий после одного пользовательского действия.

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

Наблюдение и остановка цикла

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

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

Проверка источника истины

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