ScriptRunner Cloud: проверяем REST-чтение одной задачи в консоли

Задача: отделить доступ к API от логики скрипта

При переносе скрипта или разборе ошибки полезно сначала получить одну известную задачу без обновлений и массового поиска. Если этот шаг не работает, обход сотен задач только усложнит диагностику. В этом руководстве Script Console используется для ограниченного GET: проверяем код HTTP, границу проекта и несколько технических идентификаторов.

Материал относится к ScriptRunner for Jira Cloud и Jira Cloud REST API v3. Облачное приложение взаимодействует с Jira через REST; серверные Java API и ComponentAccessor из Data Center сюда не переносятся. Используется актуальная облачная документация без утверждения о совместимости с каждым прежним вариантом интерфейса.

Ниже дан учебный фрагмент Groovy и план его проверки. Код не компилировался и не выполнялся в реальной Jira или среде заказчика. Он не создаёт задач, не меняет поля и не отправляет уведомлений; результат чтения не является разрешением запускать отдельный скрипт записи.

Подготовьте учебную задачу и доступ к консоли

Нужен тестовый Jira Cloud-сайт с установленным ScriptRunner, разрешённый доступ администратора к Script Console и одна безвредная задача проекта PILOT. Запишите её фактический ключ, тип и статус. Если номер отличается от PILOT-1, замените только константу issueKey. Ключ проекта в защитных проверках тоже должен соответствовать согласованной учебной области.

По документации ScriptRunner доступ к Script Console относится к глобальному администрированию. Не выдавайте такую роль обычному читателю ради одного диагностического отчёта. Владелец приложения может выполнить разрешённую проверку и передать минимальный результат. Отдельно подтвердите возможность открыть выбранную задачу в интерфейсе.

Для первого запуска не берите заявку с персональными данными, вложениями или секретами. Подготовьте протокол: сайт, ключ, пользователь запуска, ожидаемый HTTP-результат и два технических ID. Этого достаточно, чтобы сравнить чтение API с наблюдениями в интерфейсе, не сохраняя полный JSON задачи.

Выберите пользователя запуска до Run

В Script Console запросы к Jira можно выполнять от ScriptRunner Add-on User или Current User. Запишите выбранный вариант до запуска. Это часть условий эксперимента: успешное чтение от приложения не подтверждает возможность такого же чтения обычным сотрудником.

Для диагностики собственного доступа сначала используйте Current User, если это соответствует задаче и разрешениям администратора. Для разбора конкретного фонового сценария потребуется отдельно установить его действительный контекст. Не считайте настройки консоли автоматическим воспроизведением поведения Listener, Scripted Field или workflow-функции.

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

Запросите только нужные поля

Пример использует встроенный HTTP-клиент ScriptRunner: относительный путь Get issue, параметр fields и преобразование ответа через asObject(Map). Токен, пароль и заголовок Authorization в код не вставляются. Речь идёт о запросе из установленного приложения, а не об отдельном внешнем клиенте REST API.

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

В результате остаются ключ, HTTP-статус, ID статуса и ID типа задачи. Summary, description, комментарии и сведения о пользователях не выводятся. Если для следующего шага нужно ещё одно поле, добавляйте его осознанно после проверки этого минимального фрагмента.

final String issueKey = 'PILOT-1'

if (!(issueKey ==~ /PILOT-[1-9][0-9]*/)) {
    throw new IllegalArgumentException('Only PILOT keys are allowed')
}

def response = get("/rest/api/3/issue/${issueKey}")
    .header('Accept', 'application/json')
    .queryString('fields', 'project,status,issuetype')
    .asObject(Map)

if (response.status != 200) {
    return [requestedKey: issueKey, httpStatus: response.status]
}

Map data = response.body
if (data?.key != issueKey || data?.fields?.project?.key != 'PILOT') {
    throw new IllegalStateException('Returned issue is outside the expected scope')
}

return [
    issueKey: data.key,
    httpStatus: response.status,
    statusId: data.fields.status?.id,
    issueTypeId: data.fields.issuetype?.id
]

Проведите положительную и отрицательную проверку

Вставьте код в ScriptRunner → Script Console, ещё раз проверьте выбранного пользователя и выполните один запуск. Для существующей доступной PILOT-1 ожидается httpStatus 200 и непустые statusId и issueTypeId. Сравните статус и тип с карточкой задачи; при необходимости сопоставьте ID с разрешёнными административными справочниками.

Для отрицательного теста замените issueKey на OTHER-1, не меняя защитные условия. Ожидается IllegalArgumentException до обращения к Jira. Это проверяет границу входных данных самого фрагмента, а не схему разрешений проекта. Затем верните исходную константу и проверьте, что в редакторе не остались случайные изменения.

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

Разбирайте HTTP-ошибку до чтения тела

Код обращается к fields только после проверки response.status. Если пришёл другой статус, он возвращает краткую диагностическую пару вместо попытки читать status.id из неподходящего ответа. Это помогает отделить отказ доступа или ошибку API от ошибки обработки структуры данных.

При 401 или 403 проверяйте аутентификационный контекст приложения и разрешения, при 404 — существование задачи и возможность её видеть. Не делайте вывод «задача удалена» по одному такому ответу. При 400 сверяйте путь и параметры с документацией выбранной операции. Если клиент не смог разобрать ответ как JSON, сначала изучите саму ошибку выполнения, не выводя в общий журнал всё тело.

При 429 учитывайте Retry-After и рекомендации Atlassian по задержке повторов. В этом учебном фрагменте нет собственного цикла повторной отправки. Не создавайте нагрузку для намеренного получения лимита. При временных сбоях также учитывайте, что HTTP-клиент ScriptRunner может выполнять документированные автоматические повторы; один Run не всегда равен одной сетевой попытке.

Проверьте структуру результата и его ограничения

Отсутствующий ID при HTTP 200 требует отдельного разбора: сверяйте поля запроса, реальное тело разрешённого учебного ответа и актуальную схему Get issue. Не подставляйте выдуманное значение по умолчанию, которое сделает ошибочный результат похожим на успешный. Для первой проверки достаточно остановиться и записать, какое ожидаемое поле не получено.

Ограничение fields уменьшает набор запрашиваемых полей, но не отменяет необходимость аккуратно обращаться с результатами. В консольном выводе могут сохраниться ключи и сообщения ошибок. Не копируйте их без проверки в публичный тикет или общую переписку. Для разбора обычно достаточно обезличенного описания шага и кода HTTP.

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

Завершение и возврат учебных настроек

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

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

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