ScriptRunner Data Center: проверяем доступ пользователя к конкретной задаче

Задача и границы диагностики

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

В учебном пилоте сравним две заранее подготовленные учётные записи на одной нейтральной задаче HAPIPILOT-1. Получим только профиль проверки, признак видимости и результат проверки разрешения Edit Issues. Затем сверим наблюдения с Permission helper и обычным входом пользователя. Это предлагаемый порядок работы, а не отчёт о выполненном аудите или тестировании клиентской Jira.

Процедура относится к Jira Data Center со ScriptRunner и HAPI. HAPI появился в ScriptRunner 7.11.0; это не обещание, что все возможности текущего раздела latest одинаковы во всех старых выпусках. Пример сверяется с актуальной документацией HAPI. Перед запуском проверьте установленную пару версий Jira и ScriptRunner и совместимость методов. Документация Atlassian по issue security сейчас открывается для Data Center 11.3; для своей версии выбирайте соответствующий раздел. Код не предназначен для Jira Cloud.

Подготовьте одну задачу и два ожидаемых профиля

Используйте тестовую среду и существующие учебные аккаунты с согласованным доступом. Первый профиль, reader, должен видеть контрольную задачу и иметь разрешение Edit Issues. Второй, restricted, должен быть исключён из просмотра этой задачи её уровнем безопасности. Имена pilot.reader и pilot.restricted в коде — заменяемые примеры.

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

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

Запишите исходное состояние: ключ, статус, уровень безопасности и последнюю запись истории задачи. Содержимое Summary, Description и комментариев для этого отчёта не требуется. Код ниже не создаёт задачи, не меняет группы, не отправляет письма и не вызывает внешние сервисы.

Разделите контекст консоли и проверяемого пользователя

Script Console — административный инструмент для разового Groovy-кода. Не добавляйте этот диагностический пример в Listener, Scheduled Job или workflow. Сначала проверьте импорты и подсказки редактора в установленной версии, затем замените ключ и два имени на согласованные учебные значения.

Задача загружается в контексте текущего запуска, поэтому выполняющий код администратор должен иметь право на её чтение. Затем canView и hasPermission вызываются для явно найденного пользователя. Мы не считаем доступ администратора результатом проверки reader или restricted.

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

Неизвестное имя, отсутствующая задача или ошибка API должны останавливать диагностику. Ошибка получения объекта не является результатом «доступ запрещён». Сначала исправьте входные параметры или совместимость, затем заново выполните ограниченную проверку.

Пример отчёта без изменения данных

Пример возвращает две небольшие записи. В поле profile выводится условная метка, а не имя, email или список групп. Если browse равен false, проверка Edit Issues намеренно пропускается и editPermission получает null. Это различает отказ просмотра и непроведённую проверку.

Методы canView(issue) и hasPermission(permission, issue) описаны Adaptavist для ApplicationUser. Первая проверка относится к конкретной задаче. Во второй используется константа разрешения Edit Issues, а не произвольный текст или название проектной роли. Скрипт не пытается реально редактировать поле.

Код приведён для технической проверки в вашей среде. Его выполнение на Jira и совместимость с установленным плагином здесь не заявляются. Успешная проверка редактором также не заменяет запуск на нейтральных контрольных данных.

import com.adaptavist.hapi.jira.issues.Issues
import com.adaptavist.hapi.jira.users.Users
import com.atlassian.jira.permission.ProjectPermissions

// Замените ключ и имена согласованными учебными значениями.
def issue = Issues.getByKey('HAPIPILOT-1')
def profiles = [
    [label: 'reader', username: 'pilot.reader'],
    [label: 'restricted', username: 'pilot.restricted']
]

profiles.collect { profile ->
    def user = Users.getByName(profile.username as String)
    assert user != null : 'Контрольный пользователь не найден'
    boolean visible = user.canView(issue)
    [
        profile: profile.label,
        browse: visible,
        editPermission: visible
            ? user.hasPermission(ProjectPermissions.EDIT_ISSUES, issue)
            : null
    ]
}

Сверьте результат с независимой проверкой

Сохраните ожидаемую матрицу до запуска. Для reader ожидаются browse=true и editPermission=true. Для restricted — browse=false и editPermission=null, потому что второй шаг пропущен. Это план проверки, а не полученный результат. Дополнительно сравните историю и поля задачи с исходным состоянием: диагностический запуск не должен их менять.

В Jira откройте Administration → System → Permission helper. Укажите того же пользователя, тот же ключ и проверяемое разрешение. Сначала разберите Browse Projects, затем Edit Issues для видимого профиля. Запишите объяснение инструмента и сопоставьте его с конфигурацией, а не только с зелёным или красным индикатором.

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

Положительный результат Edit Issues — проверка разрешения, а не доказательство успешного изменения любого поля в любом состоянии. Например, свойства workflow могут отдельно запрещать редактирование. Проверка перехода, валидации полей и бизнес-операции требует отдельного сценария.

Что проверять при расхождении

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

Доступ к проекту не означает доступ ко всем его задачам. Уровень issue security задаёт дополнительную видимость; подзадачи наследуют уровень безопасности родительской задачи. Сверяйте именно членство в применённом уровне и проектные разрешения. Само наличие названия группы в каталоге не показывает, где эта группа используется.

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

Отдельно проверьте, что в исходник не попали вызовы update, create, delete, назначение роли или запуск от другого пользователя. Получение ожидаемых значений ценой изменения среды уже не является диагностикой только для чтения.

Ограничения и безопасное использование результата

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

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

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

Завершение пилота и откат

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

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

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