Re-fetch в Jira Cloud Automation: читаем новое значение после Edit

Задача: поле изменилось, а следующий шаг видит прежний текст

Действие Edit work item успешно изменило Summary, но следующий Log action вывел прежнее название. Это не обязательно ошибка сохранения. По документации Jira Cloud ссылка {{issue}} по умолчанию содержит значения с момента запуска правила и не обновляется автоматически после каждого действия. Re-fetch work item data повторно читает поля для последующих smart values.

В учебном примере одна задача RFDEMO-1 меняет Summary с «Пилот A» на «Пилот B». Сравним историю задачи и три точки журнала: до записи, сразу после Edit и после Re-fetch. Затем условие проверит новое значение. Задача, тексты и ключ вымышлены; процедура описывает предлагаемый опыт, а не выполненный тест на клиентской Jira.

Сценарий рассчитан на Jira Cloud Automation в одном тестовом проекте. Cloud не требует выбора устанавливаемого номера версии; названия issue/work item и rule/flow меняются в интерфейсе. Re-fetch issue data — прежнее название того же действия. Для Data Center проверяйте документацию установленной версии отдельно. Плагины и сторонние действия в пилот не входят.

Подготовка: одна задача и известное исходное состояние

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

Создайте нейтральную задачу, запишите её фактический ключ и задайте Summary «Пилот A». Согласуйте короткий период, когда никто другой не будет её редактировать. Проверьте связанные правила: обычное изменение Summary может запускать другие процессы. В пилоте не должно быть реальных клиентов, секретов, внешних уведомлений и зависимостей от рабочего workflow.

Замените RFDEMO-1 во всех шагах своим ключом. Сохраните исходный текст, область действия и конфигурацию правила. Ограничьте Manual trigger тестовой группой. После сохранения проверяйте переключатель активности: новое правило может оказаться включённым по умолчанию. Не используйте расписание или массовую JQL-выборку для первой проверки.

Сначала соберите вариант только для чтения

Создайте проектное правило с Manual trigger from work item. Добавьте два последовательных условия сравнения smart values. Первое: {{issue.key}} Equals RFDEMO-1. Второе: {{issue.summary}} Equals Пилот A. В интерфейсе такое условие может называться {{smart values}} condition, Advanced compare condition или Compare two values. Для пилота сравниваем именно значения, а не результат индексного поиска.

После условий добавьте Log action с первой строкой из блока ниже. Сохраните правило и вручную запустите его из меню действий учебной задачи. В некоторых вариантах интерфейса ручные правила находятся в Flow executions. Откройте соответствующее выполнение в Audit log и проверьте ключ и исходный Summary.

Попробуйте тот же ручной запуск на другой нейтральной задаче, если она входит в область правила. Первое условие должно остановить дальнейшие действия. Если журнал показывает другой ключ или условия настроены на «любое из», не добавляйте изменение поля. Здесь нужна последовательная проверка обоих ограничений.

phase=before key={{issue.key}} summary={{issue.summary}}

Добавьте Edit и повторное чтение в правильном месте

После первого Log action добавьте Edit work item: выберите Summary и установите буквальный текст «Пилот B». Используйте обычный выбор поля, без дополнительного JSON. Затем добавьте второй Log action, действие Re-fetch work item data и третий Log action. Порядок строк ниже соответствует порядку выполнения; это содержимое отдельных шагов журнала, а не импортируемый JSON правила.

Сразу после третьего журнала добавьте условие {{issue.summary}} Equals Пилот B и ещё один Log action: phase=verified key={{issue.key}}. Последняя отметка должна появляться только при успешном сравнении. Не размещайте условие до Re-fetch: иначе проверяться будет значение из другого момента выполнения.

Сохраните изменения. Перед единственным пробным запуском ещё раз откройте RFDEMO-1 и подтвердите исходный текст «Пилот A». Если предыдущая попытка уже записала «Пилот B», сначала разберите её результат и выполните согласованный возврат. Повторный щелчок запуска не является способом исправить непонятный результат.

Log action:
phase=before key={{issue.key}} summary={{issue.summary}}

Edit work item: Summary = Пилот B

Log action:
phase=after-edit-before-refetch key={{issue.key}} summary={{issue.summary}}

Re-fetch work item data

Log action:
phase=after-refetch key={{issue.key}} summary={{issue.summary}}

Compare two values: {{issue.summary}} Equals Пилот B

Log action:
phase=verified key={{issue.key}}

Как оценивать результат

Это ожидаемая матрица, а не утверждение о выполненном испытании. Первая строка должна показывать «Пилот A». В истории задачи должна появиться запись об изменении Summary на «Пилот B». Строка между Edit и Re-fetch демонстрирует, почему нельзя рассчитывать на автоматическое обновление снимка {{issue}}: сохранённое поле и прочитанное smart value проверяются отдельно.

После Re-fetch ожидаются «Пилот B» и отметка phase=verified. Сверьте именно одно выполнение по ключу, порядку шагов и времени, а не строки из нескольких запусков. Успешный общий статус правила недостаточен: нужна история записи и достижение контрольной отметки. Отсутствие отметки требует просмотра условия, после которого выполнение остановилось.

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

• Другая задача: правило не доходит до Edit, её поля не изменяются.
• Целевая задача уже имеет «Пилот B»: начальное условие не допускает повторной записи.
• Правильная задача с «Пилот A»: запись отражается в истории, после повторного чтения выполняется сравнение с «Пилот B».
• Нет права редактирования: зафиксирована ошибка Edit; её не следует объяснять отсутствием Re-fetch.
• Контрольная отметка отсутствует: проверены результат Re-fetch, точное написание текста и контекст текущей задачи.

Если новое значение всё ещё не видно

Начните с действия записи. Если Edit завершился ошибкой, повторное чтение не создаст отсутствующее изменение. Проверьте исполнителя, доступность задачи, редактируемость поля и сообщение конкретного шага. Если запись подтверждена, убедитесь, что Re-fetch стоит после неё и перед первым потребителем нового значения. Лишнее повторное чтение в начале правила эту зависимость не исправляет.

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

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

Границы метода и ограничение нагрузки

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

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

Сервисные ограничения Automation и квоты плана проверяйте в своей среде. Не вставляйте Re-fetch после каждого шага без зависимости по данным и не запускайте сотни опытов для подтверждения простого сравнения. Одного ограниченного пилота с понятным журналом достаточно для начала; масштабирование требует отдельной оценки времени выполнения и нагрузки.

Остановка и возврат исходного состояния

Отключите пилотное правило и убедитесь, что оно больше не доступно для обычного запуска. Проверьте уже начатые выполнения по журналу. Отключение не отменяет сохранённые изменения Summary и не является автоматическим откатом.

Откройте историю RFDEMO-1. Если последнее подтверждённое изменение относится к пилоту и текущее значение равно «Пилот B», согласованно верните «Пилот A». Если после пилота появились другие изменения, остановитесь и разберите их с владельцем задачи: слепая запись исходного текста может уничтожить полезное исправление. Контрольные задачи и журналы сохраните до завершения сверки.

Перед переносом приёма в рабочее правило сделайте копию конфигурации и отметьте конкретную зависимость: какой шаг записывает поле, какой должен прочитать новое состояние и где стоит Re-fetch. Проверьте положительный, отрицательный и повторный запуск на тестовой задаче. Только после этого добавляйте действия с клиентскими уведомлениями или изменением связанных объектов.