Manual trigger в Jira Cloud: собираем данные перед запуском правила

Задача: одинаковая первичная проверка без копирования текста

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

Используем Manual trigger from work item в Jira Cloud Automation. Пользователь запускает правило из задачи, заполняет входные поля, а правило формирует комментарий. Статус, исполнитель и права доступа остаются за пределами этого сценария. Сначала сделаем вариант только с записью в audit log, затем отдельно проверим действие добавления комментария. Ручной запуск выполняет настроенные действия: сам по себе он не является режимом симуляции.

Применимость, права и подготовка

Инструкция предназначена для обычного внутреннего проекта Jira Cloud с доступной Automation. У облака нет единой фиксированной версии установки; названия Rule и Flow, а также Issue и Work item могут различаться в интерфейсе. Для Data Center проверяйте документацию установленной версии отдельно. Здесь не используется клиентский портал JSM: видимость внутренних и публичных комментариев требует другого пилота.

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

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

Шаг 1. Настройте триггер и поля формы

Откройте Automation в настройках тестового проекта и создайте отдельное правило «Пилот: результат первичной проверки». Выберите Manual trigger from work item. Ограничьте запуск согласованной группой через Groups that can run trigger. Не оставляйте широкую аудиторию на время эксперимента. Область правила ограничьте пилотным проектом.

Включите получение данных от пользователя: в интерфейсе это может называться Get input from users или Prompt for input when this rule is triggered. Добавьте Dropdown (Single choice) с подписью «Результат проверки», двумя вариантами ready и needs-info и именем переменной triageDecision. Сделайте выбор обязательным. Добавьте необязательное текстовое поле «Пояснение» с переменной triageNote; в подсказке попросите писать коротко и не включать секреты.

Эти поля принадлежат форме запуска. Они не создают и не обновляют одноимённые custom fields задачи автоматически. Для нашего сценария дополнительные поля Jira не нужны. Значения доступны как userInputs с именем переменной. Используйте буквенные имена без пробелов; не называйте переменные просто 1 или 2 — Atlassian описывает связанный с такими именами сбой формы.

{{userInputs.triageDecision}}
{{userInputs.triageNote}}

Шаг 2. Проверьте входные данные через Log action

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

Откройте первую тестовую задачу, найдите правило в меню Actions и выберите ready. Затем посмотрите соответствующее выполнение в audit log. Ожидается ключ именно этой задачи и выбранное значение. Повторите на второй задаче с needs-info и сверяйте запуск с нужной задачей, а не с соседней записью журнала. Это предлагаемые проверки; они не заявлены выполненными на вашем Cloud-сайте.

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

triage-preview | issue={{issue.key}} | decision={{userInputs.triageDecision}}

Шаг 3. Добавьте только разрешённые варианты действия

После проверки предпросмотра остановите пилотное правило и добавьте блок If/else. В первой ветке используйте условие сравнения smart values: {{userInputs.triageDecision}} равно ready. Во второй ветке сравните то же значение с needs-info. В остальных случаях оставьте только диагностическую запись о неподдерживаемом решении. Такой порядок делает поведение понятным после будущего изменения списка вариантов.

В разрешённых ветках добавьте Comment on work item, в старом интерфейсе — Comment on issue. Для ready используйте фиксированную формулировку «Первичная проверка: можно продолжать работу», для needs-info — «Первичная проверка: нужны дополнительные сведения». После неё вставьте triageNote. Не добавляйте переход workflow или назначение исполнителя в тот же пилот: сначала отдельно подтвердите комментарий и его видимость.

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

Первичная проверка: можно продолжать работу.
Пояснение: {{userInputs.triageNote}}

Проверка результата и отрицательные сценарии

Включите изменённый пилот и выполните контрольные сценарии ниже. Для каждого сохраните ключ задачи, выбранный вариант, запись audit log и наблюдаемый комментарий. Сам по себе успешный статус выполнения не подтверждает правильность смысла сообщения или аудитории. Сравните автора комментария с настроенным actor и проверьте, что задача не получила посторонних изменений.

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

• ready с нейтральным пояснением: появляется комментарий с первой формулировкой именно в выбранной задаче.
• needs-info с другим пояснением: используется вторая формулировка, без изменения статуса и исполнителя.
• Пустое необязательное пояснение: обязательное решение сохраняется, комментарий остаётся понятным без заметки.
• Не выбран обязательный результат или форма отменена: запись в задаче не создаётся.
• Пользователь вне группы: правило нельзя использовать из задачи; действие записи не выполняется.
• Повторный запуск: поведение соответствует согласованной политике, предыдущий результат проверен до повторной отправки.

Типовые ошибки: нет формы, пустые данные, отказ записи

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

Если Log action распознаёт данные, а комментарий не появляется, проверьте выбранную ветку, actor и полномочия на добавление комментариев. Не меняйте одновременно группу, исполнителя и все условия: исправляйте одну причину и повторяйте опыт на тестовой задаче. Если комментарий появляется в неожиданном месте, ищите добавленную ветку по связанным задачам или расширенную область правила.

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

Откат и передача правила владельцу

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

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

Перед расширением сохраните имя владельца правила, группу запуска, actor, область, значения ready/needs-info и правила обращения с пояснением. Приложите результаты собственной приёмки. Эта статья проверена по официальной документации; настройки в реальной Jira не изменялись и выполненные клиентские испытания не заявляются.