В этой статье я поделюсь результатами исследования, посвященного унификации процессов создания проектов в Jira, используя возможности автоматизации и API. Статья была написана с помощью GPT Deep Research в целях изучения различных подходов к унификации рабочих процессов и настройки проектов в Jira. Основная цель — собрать мнения и комментарии от других экспертов, чтобы понять, как они подошли к созданию стандартов и оптимизации процессов в своей практике. Буду рад услышать ваши истории и советы по унификации в Jira, а также обсудить лучшие методы для повышения эффективности и согласованности в работе команд.

Создание проекта через REST API Jira

В Jira Server/Data Center начиная с версии 7.0 появилось REST API для создания проектов. Основной endpoint – POST /rest/api/2/project. Запрос должен выполняться от имени пользователя с правами администратора Jira (только администраторы могут создавать проекты программно)​. В теле запроса указываются ключевые параметры проекта: ключ, название, тип проекта и шаблон. Например, для создания Software-проекта Scrum через REST необходимы поля:

{
  "key": "SOF",
  "name": "Software Sample",
  "projectTypeKey": "software",
  "projectTemplateKey": "com.pyxis.greenhopper.jira:gh-scrum-template",
  "lead": "admin",
  "assigneeType": "PROJECT_LEAD",
  "description": "Example Project description"
}

Как видно, указываются projectTypeKey и projectTemplateKey для выбора типа проекта (software, business, service_desk) и конкретного шаблона. Шаблон определяет базовые схемы и настройки проекта. Например, шаблон Scrum создаст проект с типичными схемами для Scrum-проекта.

Параметры схем в REST API: Jira REST позволяет сразу привязать некоторые схемы при создании проекта. В JSON-запрос можно добавить ID существующих схем: issueSecurityScheme, permissionScheme, notificationScheme и workflowSchemeId. Если эти поля указаны, Jira прикрепит к новому проекту соответствующие уже существующие схемы (с указанными ID). Если не указать схемы, будут использованы схемы по умолчанию: например, дефолтная схема прав и уведомлений, а для workflow – автоматически сгенерированная или стандартная схема по шаблону. Важно: REST не позволяет напрямую указать схему типов задач или экранов – таких параметров нет​. Это означает, что при обычном создании каждый новый проект получает либо новую копию схемы экранов по умолчанию, либо разделяет существующую (в зависимости от шаблона). Аналогично и с схемой типов задач: REST не даёт выбрать кастомную схему типов задач, она назначается автоматически на основе шаблона.

Ограничения при создании проекта через REST: API создаст проект только на основе существующих элементов конфигурации. Он не генерирует новый workflow или статусы, не создаёт новые поля или экраны по вашему описанию – только либо берёт стандартные из выбранного шаблона, либо прикрепляет указанные вами готовые схемы. Например, нельзя через REST динамически создать совершенно новый workflow с набором статусов и транзиций – можно лишь привязать к проекту уже существующий workflow scheme (с ранее настроенными workflow)​. Если не указать workflowSchemeId, Jira по умолчанию может создать новую копию схемы workflow соответствующего шаблона или использовать общую (зависит от типа шаблона). В итоге, стандартный REST покрывает базовое создание проектов и привязку некоторых схем, но не покрывает создание с нуля всех элементов конфигурации (workflow, issue type scheme, screen scheme и т.д. нужно подготовить заранее либо принять дефолтные).

Создание проекта на основе шаблона (shared configuration)

Если требуется создавать проекты, полностью копируя настройки другого проекта (т.е. использовать существующие схемы и конфигурации без их дублирования), Jira Server/DC предоставляет скрытый механизм “Shared Configuration”. Это аналог опции “Share configuration” в UI Jira. С помощью него новый проект будет использовать те же схемы, что и указанный образец, без создания новых копий.

Для этого используется REST endpoint плагина шаблонов проекта:

POST /rest/project-templates/1.0/createshared/<PROJECT-ID>

где <PROJECT-ID> – ID существующего проекта-шаблона, настройки которого нужно разделить. Тело запроса содержит хотя бы key, name и lead для нового проекта​. Пример (cURL) создания проекта с ключом NPABC на основе проекта с ID 10200:

curl -u admin:password -X POST -H "Content-Type: application/json" \
  -d '{"key": "NPABC", "name": "New Project ABC", "lead": "able3"}' \
  http://<JIRA-BASE-URL>/rest/project-templates/1.0/createshared/10200

Этот запрос вернётся с кодом 200 и создаст проект, который разделяет все схемы с проектом 10200​. Таким образом, новый проект будет иметь тот же набор типов задач, workflow, экраны, поля, схемы прав и уведомлений и пр., что и исходный.

Особенности и ограничения: Endpoint createshared не задокументирован официально в общедоступной документации REST, но Atlassian привёл его в базе знаний как решение для копирования конфигурации​. Этот метод требует, чтобы эталонный проект с нужной конфигурацией уже существовал. Он не позволяет частично изменять конфигурацию – новая проекты будут точно повторять схемы исходного. Данный подход удобен для реализации собственных “шаблонов проектов”: администратор заранее настраивает ряд образцовых проектов (с нужными наборами issue types, workflow, полями и т.д.), а внешний скрипт через createshared быстро создаёт их копии.

Учтите, что createshared так же, как и обычный POST /project, требует аккаунт с правами админа. Кроме того, он копирует ссылку на те же схемы, а не дублирует их – поэтому изменение схемы (например, workflow) в одном из проектов-шареров повлияет и на другой. Если нужна независимая копия (форк конфигураций), то этот способ не подходит – придётся создавать новые схемы вручную или программно.

Управление элементами конфигурации через API

Проект Jira состоит из множества связанных схем и объектов конфигурации: типов задач, рабочих процессов (workflow), схем workflow, экранов, схем экранов, конфигураций полей, схем разрешений (permission scheme), схем уведомлений и др. Создать полностью кастомный проект с нуля означает настроить все эти компоненты. Рассмотрим, какие из них можно управлять через доступные API Jira Server/DC, а какие – нет.

Рабочие процессы (Workflow) и схемы рабочих процессов

Создание/редактирование workflow через REST: В Jira Server нет публичного REST API для создания нового workflow или изменения его статусов/переходов. Atlassian прямо указывает, что ни SOAP (устаревший XML-RPC API), ни REST не предоставляют таких функций​. Workflow можно создавать и настраивать только через интерфейс администратора или с помощью Java API (внутри плагинов/скриптов). Соответственно, полностью программно снаружи (REST) вы не сможете сгенерировать новый набор статусов и переходов под каждую кастомную задачу.

Управление схемами workflow через REST: Непосредственно после создания проекта можно назначить ему существующую схему workflow, указав workflowSchemeId в запросе (как описано выше). Также в версиях Jira Server/DC существуют некоторые REST-эндпоинты для работы с workflow schemes – например, получить список схем, создать черновик схемы, публиковать черновик и т.п. (они в основном использовались в Jira Cloud и позже портированы в DC). Однако даже если REST позволяет создать пустую схему workflow (POST /rest/api/2/workflowscheme), эта схема всё равно должна использовать уже существующие workflow. Mapping workflow->issueType можно менять через REST (в Cloud/DC API есть методы привязки workflow к типу задач в схеме). Но повторимся: сами новые workflow (наборы статусов и переходов) должны существовать заранее.

Практически, подход может быть таким: администратор вручную (или через Groovy-скрипт) заранее создаёт нужные кастомные рабочие процессы в Jira и сохраняет их в системе. Затем внешний скрипт при создании проекта через REST указывает ID схемы workflow, куда включён этот кастомный процесс. Если же требуются уникальные workflow под каждый проект, REST API бессилен – потребуется задействовать Java API или вручную копировать workflow через UI.

Типы задач и схемы типов задач

Типы задач (Issue Types): Добавлять новые типы задач или изменять их свойства также нельзя через публичный REST. Jira предоставляет REST для чтения списка типов задач, но не для создания новых. Поэтому любые пользовательские типы задач должны быть либо заранее созданы администратором, либо создаваться кодом внутри Jira (через Java API).

Схема типов задач: Эта схема определяет, какие типы задач доступны в проекте. При создании проекта через REST, схема типов выбирается автоматически на основе шаблона. Например, Software-проект Scrum получит схему, включающую Epic, Story, Task, Bug etc. Явно указать свою схему типов задач в REST запросе нельзя. Если нужна особая комбинация типов задач, есть несколько путей:

  • Создать проект с опцией shared configuration – тогда он унаследует схему типов задач от шаблонного проекта, в котором уже настроен нужный набор.

  • Создать проект по стандартному шаблону, а затем программно (через Java API либо с помощью админских инструментов) сменить ему схему типов задач на другую существующую. Прямого REST-запроса для привязки другой issue type scheme нет, но в Java API есть соответствующие сервисы.

  • Ещё вариант – плагин или ScriptRunner-скрипт: он может через IssueTypeSchemeManager создать новую схему, добавить в неё нужные типы, и присвоить проекту.

В общем, управление типами задач – администрационная операция, не автоматизируемая простым REST-вызовом, за исключением использования уже существующих схем.

Пользовательские поля и экраны

Создание кастомных полей: Jira Server/Data Center позволяет создавать поля через REST API. Эндпоинт: POST /rest/api/2/field. В теле нужно задать имя поля, тип (например, com.atlassian.jira.plugin.system.customfieldtypes:textfield) и подходящий searcherKey. Этот вызов создаст новое пользовательское поле в системе (глобально). Однако, после создания поля его нужно добавить на экраны, иначе оно не будет отображаться в формах создания/редактирования задач.

Добавление поля на экран: Имеется REST для добавления существующего поля на экран: POST /rest/api/2/screens/{screenId}/tabs/{tabId}/fields. Т.е. зная ID экрана и ID вкладки, можно программно прикрепить поле. По умолчанию при создании нового поля Jira может автоматически добавить его на экран по умолчанию (Default Screen)​, но для других экранов требуется явное добавление. Вызовы для получения списка экранов и вкладок тоже существуют (например, GET /rest/api/2/screens и затем GET /rest/api/2/screens/{screenId}/tabs). В Jira Server экраны каждого проекта зависят от применённой схемы экранов (Screen Scheme). Если проект использует уникальные экраны, их ID придётся выяснять через API или заранее фиксировать.

Создание экранов и схем экранов: Публичный REST для создания нового экрана (POST /rest/api/2/screens) существует в Jira Cloud и, начиная с определённых версий, в Data Center​. Однако в старых версиях Jira Server такой метод может отсутствовать. Даже если он есть, придётся затем связывать экран с схемой экранов и схемой экранов типов задач. Прямого REST для создания Screen Scheme и Issue Type Screen Scheme нет. Обычно их готовят вручную или скриптом. Таким образом, наиболее реалистично – при автоматизированном создании проекта переиспользовать существующие экраны/схемы, либо создавать их внутри Jira через Java API. На практике, если использовать типовой шаблон при создании проекта, Jira сама создаст стандартные три экрана (Create/Edit/View) и свяжет их со схемой экранов и схемой экранов типов задач по умолчанию. Далее скрипт может просто добавить нужные поля на эти экраны через REST.

Конфигурации полей (Field Configuration): Эти объекты определяют настройки полей (обязательное/необязательное, подсказки и т.п.) и группируются в Field Configuration Scheme. К сожалению, REST API для создания/изменения Field Configuration (Scheme) отсутствует. Их тоже можно только назначать вручную или через Java API. Обычно проекты используют дефолтную конфигурацию полей, если не указано иное.

Схемы разрешений и уведомлений

Назначение схем прав (Permission Scheme): В REST API создания проекта можно сразу указать permissionScheme с ID существующей схемы. Если не указать, Jira прикрепит схему по умолчанию (Default Permission Scheme). Создать новую схему прав через REST нельзя – предполагается, что администратор заранее создал нужные схемы (например, отдельная схема под проекты определённого типа), и вы просто указываете её ID при создании. В противном случае придётся менять схему после создания проекта вручную или с помощью Java API (PermissionSchemeManager).

Схема уведомлений: Аналогично, при создании можно задать notificationScheme (ID уже существующей схемы уведомлений). Без этого будет применена схема по умолчанию. Создание новых схем уведомлений через REST не поддерживается – только выбор из существующих.

Схема безопасности задач (Issue Security): Если используется уровень безопасности, можно указать issueSecurityScheme при создании. Это тоже должна быть заранее созданная схема безопасности.

Таким образом, REST покрывает привязку основных административных схем (права, уведомления, безопасность) если они уже есть. Но само создание этих схем – прерогатива администратора через UI или скрипты.

Правила автоматизации (Automation Rules)

Automation for Jira (правила автоматизации) – это отдельный функционал (в виде приложения или встроенный, в зависимости от версии Jira). К сожалению, ни Jira Server, ни Data Center не предоставляют публичного REST API для создания или изменения правил автоматизации. В официальном запросе на фичу Atlassian признала: “It is not possible to create, edit, delete, enable or disable automation rules using a REST API.”. То есть, вы не можете программно добавлять новые правила автоматизации в проект или включать/выключать их – это делается вручную через интерфейс (или путем импорта/экспорта правил, что тоже полуавтоматично).

Если автоматизация задач – критичная часть шаблона проекта, есть два пути:

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

  • ScriptRunner-скрипты вместо Automation: Использовать ScriptRunner (или другой плагин) для реализации логики, аналогичной Automation Rules, и запускать эти скрипты при событиях (создание задачи и др.). ScriptRunner позволяет писатьListeners и Post-functions, которые могут действовать как автоматизация.

Имейте в виду, что на 2025 год API для Automation в серверной Jira всё ещё недоступен (в отличие от Jira Cloud, где Atlassian постепенно открывает API для Automation).

Ограничения API и требуемые права

Вышеописанные возможности показывают, что REST API Jira Server/DC имеет существенные ограничения по управлению конфигурацией:

  • Можно автоматически создать проект и указать некоторые схемы (права, уведомления, безопасность, workflow scheme), а также тип/шаблон проекта.

  • Нельзя через REST создать: новый workflow (набор переходов)​, новый статус, новый тип задачи, новую схему типов задач, схему экранов, схему полей, схему прав/уведомлений. Эти элементы должны быть либо уже определены в системе, либо создаваться другим способом.

  • Имеются частичные средства REST для: добавления поля (custom field), привязки поля к экрану, создания экранов (в последних версиях) и управлением workflow-схемами (черновики, публикация и т.п.). Но без внутренних API всё равно не обойтись, если нужна глубокая кастомизация.

  • SOAP/XML-RPC: Ранее Jira имела SOAP API, но он официально устарел и отключён. К тому же, как подтвердили в Atlassian, SOAP тоже не умел управлять схемами конфигурации​. Так что старые XML-RPC методы не помогут.

  • Automation API отсутствует (для Server/DC)​, поэтому автоматизацию конфигураций проекта средствами Automation for Jira автоматизировать нельзя.

Кроме технических ограничений, важно помнить и про требования прав: все описанные действия требуют административного доступа. Создание проектов, схем, полей, workflow – всё это доступно только администратору Jira. Поэтому интеграционное решение должно выполняться от имени сервисной учётной записи администратора. Например, вызовы REST делаются с Basic-Auth админа либо с использованием PAT (token) с правами админа. Если используется ScriptRunner или собственный плагин, он должен работать с привилегиями администратора (в ScriptRunner код выполняется с правами пользователя, который вызвал endpoint; такой пользователь тоже должен быть админом для большинства операций).

Альтернативные подходы: Java API, ScriptRunner, CLI

Чтобы преодолеть ограничения REST, можно воспользоваться внутренними API Jira (Java API), разрабатывая плагин или используя ScriptRunner (Groovy-скрипты), либо применять сторонние утилиты, такие как Jira CLI.

  • Разработка плагина (Jira SDK, Java API): Этот подход подразумевает создание Type-2 add-on (плагина) и использование сервисов Jira напрямую. Atlassian поддержка отмечала, что для полной автоматизации проектов проще написать плагин, выполняющий все необходимые шаги, чем пытаться расширить REST. В плагине вы получаете доступ к менеджерам и сервисам:

    • ProjectService/ProjectManager: для создания проекта программно (например, метод createProject с ProjectCreationData). Это обходит REST и позволяет указать схемы, категорию и пр. Плагин может как сам создавать новые схемы на лету, так и применять существующие.

    • WorkflowManager/WorkflowSchemeManager: для создания нового workflow (или копирования существующего) и для сборки схемы workflow (mapping issue types to workflows). Через эти API можно програмmatically создать статусы, transitions, условия – фактически скрипт может сгенерировать workflow под нужный набор статусов.

    • IssueTypeManager: создание новых типов задач, если нужно.

    • CustomFieldManager: создание кастомных полей (аналогично REST, но через Java) и FieldLayoutManager/ScreenManager для экранов и схем экранов.

    • PermissionSchemeManager/NotificationSchemeManager: создание схем прав/уведомлений и их привязка.

    Плагин может предоставлять собственный REST endpoint (через модуль rest) или слушать события, или иметь UI в Jira. В нашем случае можно сделать REST endpoint, который принимает JSON с параметрами проекта (из внешней формы) и внутри Jira выполняет все шаги конфигурации. Этот подход наиболее гибкий: всё, что админ делает через UI, можно повторить через Java API, т.к. Jira сама использует эти API внутри. Минус – требуется писать и поддерживать плагин, знание Jira SDK, и установка его в Jira.

  • ScriptRunner (Groovy): ScriptRunner for Jira (Data Center) – популярный плагин, упрощающий доступ к Java API. С ним можно написать Groovy-скрипт, который будет делать то же, что и описано выше, но без полноценной упаковки в отдельный плагин. Например, ScriptRunner позволяет определить REST Endpoint на Groovy: вы пишете скрипт, регистрируете его под URL (через конфиг ScriptRunner), и затем внешний сервис вызывает этот URL. Скрипт получает параметры и вызывает Java API Jira. Adaptavist (разработчик ScriptRunner) приводит пример, что скриптом можно даже автоматически создать проект со всеми кастомными схемами в post-function workflow или REST Endpoint​. По сути, ScriptRunner даёт возможность реализовать “самодельный API” для создания проектов.

    Пример возможностей ScriptRunner: можно использовать ProjectService.createProject(...) для создания проекта. Затем в том же скрипте:

    • Создать копию существующего workflow (или с нуля с помощью WorkflowManager – хотя это более сложный процесс, часто проще копировать шаблонный workflow и править его).

    • Через WorkflowSchemeManager создать новую Workflow Scheme, привязать к ней новый workflow для определённых типов задач, и назначить эту схему проекту.

    • Создать новые кастомные поля (CustomFieldManager.createCustomField), если требуются, и сразу добавить их на нужные экраны (FieldScreenManager и связанные объекты).

    • При необходимости, создать новые статусы (ConstantsManager/StatusManager) – хотя обычно стараются использовать уже существующие статусы, чтобы не плодить дубликаты.

    • Настроить Permission Scheme: либо скопировать существующую через API и модифицировать, либо привязать общую.

    • Аналогично с Notification Scheme.

    Таким образом, одним скриптом можно выполнить весь pipeline создания кастомного проекта, минуя ограничения REST. Скрипт запускается с правами админа, поэтому проблем с доступом нет. В Atlassian Community есть примеры и обсуждения такого подхода (например, создание проекта через ScriptRunner с помощью ProjectService и проверкой ErrorCollection на результат).

  • Atlassian CLI (Command Line Interface): Это сторонний инструмент (от Appfire, ранее Bob Swift) – не API как таковой, а утилита, выполняющая команды Jira через комбинацию REST, SOAP или внутренних вызовов. CLI умеет создавать проекты и на лету назначать им схемы, даже те, которые недоступны в официальном REST. Например, команда createProject в Jira CLI поддерживала указание workflow схемы, схемы экранов и т.д., чего нет в REST​. Однако CLI имеет свои ограничения: по данным разработчиков, он не умеет на лету создавать/назначать Screen Scheme (экраны всё равно придётся вручную править)​. Использование CLI может быть вариантом, если не хочется писать код: ваш внешний бэкенд может вызывать CLI команду с нужными параметрами. Но это добавляет зависимость от доп. инструмента и требует установки CLI (и, конечно, админских прав).

  • Готовые решения в Marketplace: Помимо CLI и ScriptRunner, существуют приложения для Jira Server/DC, облегчающие клонирование или шаблоны проектов. Например, плагин Project Templates (существуют реализации на GitHub​) или коммерческие решения позволяют определять набор конфигураций и потом создавать проекты из шаблона через UI. Некоторые администраторы просто используют UI Jira с опцией "Create with shared configuration" (как автоматизировать – описано выше). Если цель – именно предоставить внешний интерфейс для пользователей (вне Jira) и автоматизировать процесс, то наибольшей гибкости даст собственная интеграция (REST + ScriptRunner).

Вывод: Atlassian прямо указывает, что без плагина не обойтись для полной автоматизации: “SOAP and REST APIs do not have those functions... you will need to write add-ons to provide the functions... it’s easier to simply write add-ons that do all the work”​. ScriptRunner можно рассматривать как уже готовый “аддон”, где нужно лишь написать скрипт. CLI – как альтернативный подход без разработки, но с ограничениями. Выбор зависит от того, хотите ли вы минимизировать код (тогда CLI + существующие шаблоны) или максимально настроить под себя (тогда Java/Groovy код).

Рекомендации по реализации внешнего UI и бэкенда

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

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

  • Какие типы задач нужны в проекте (из заранее определённого списка доступных типов).

  • Какой workflow использовать для каждой категории задач (например, отдельный workflow для багов, другой для тасков и т.д.).

  • Какие стадии/статусы нужны (или выбор из шаблонов workflow).

  • Необходимые кастомные поля и их типы.

  • Наборы разрешений (возможно, выбор из "открытый проект", "приватный проект" и т.п. – что мапится на различные permission schemes).

  • Нужна ли настройка уведомлений (например, брать стандартную или особую схему).

  • Прочие параметры: категория проекта, лидер проекта, ключ и название проекта и т.д.

После заполнения формы пользователь отправляет запрос (Submit).

Бэкенд-сервис: получает данные из формы и выполняет серию действий для создания проекта в Jira. Здесь есть два основных подхода:

1. Оркестрация через REST API Jira: Бэкенд последовательно вызывает Jira REST API, используя учётку администратора:

  1. (Опционально) Подготовка конфигураций: например, если пользователь выбрал какие-то совершенно новые элементы, отсутствующие в Jira, бэкенд не сможет создать их через REST. Поэтому этот подход лучше работает, если UI предлагает только уже существующие варианты (например, списки типов задач, которые уже есть в Jira, наборы workflow, которые админ заранее настроил). Иначе подготовка нестандартных вещей требует отдельного шага (см. подход 2).

  2. Создание проекта: вызывать POST /rest/api/2/project. Здесь решается, какой шаблон и параметры использовать:

    • Если пользователь выбрал "на основе проекта-шаблона X", можно вместо этого вызвать POST /rest/project-templates/1.0/createshared/X​. Тогда проект сразу скопирует конфиг проекта X.

    • Иначе, выбрать наиболее близкий тип/шаблон. Например, если нужен софтверный проект с доской – использовать projectTypeKey=software и projectTemplateKey Scrum или Kanban. Если бизнес-процесс – business и соответствующий шаблон.

    • Включить в тело JSON доступные схемы: permissionScheme и notificationScheme если они выбраны (ID берутся из соответствия выбора пользователя). workflowSchemeId можно указать, если заранее подготовлена схема workflow под данный набор (см. ниже).

  3. Настройка после создания: если проект создан без shared configuration, Jira могла сгенерировать ему новые схемы по умолчанию. Далее бэкенд может выполнить дополнительные REST-вызовы:

    • Привязка workflow-схемы: Если нельзя было указать на шаге 2 нужную схему (например, пользователь хочет особый набор workflow для разных Issue Type), то после создания можно поменять схему workflow проекта. К сожалению, прямого REST для "сменить схему workflow проекта" нет – нужно использовать Jira Java API или, как workaround, возможно REST для workflow scheme: создать новую схему (POST .../workflowscheme) и ассоциировать с проектом (PUT .../workflowscheme/project?projectId=). В последних версиях Jira Server/DC могли добавить такой endpoint (в Jira Cloud он есть). Если REST не справится, придётся задействовать Groovy-скрипт.

    • Поля и экраны: создать недостающие кастомные поля (POST /field). Затем добавить их на экраны проекта. Если известны ID экранов (например, через GET /rest/api/2/project/{projectKey}?expand=description,projectKeys,... – но там экранов нет; придётся искать по имени схемы экранов, которая обычно называется как "<Project Name> Software Default Screen Scheme" и доставать ее ID). Далее добавить поля на каждый экран (Create, Edit, View) через POST /screens/{id}/tabs/{id}/fields.

    • Issue Type Scheme: если нужно ограничить типы задач, а REST не позволил это задать, можно вручную убрать лишние типы через Java API (REST не умеет). Например, через Edit Issue types for project (нет публичного, но internal API).

    • Permission/Notification schemes: если на шаге 2 не назначили их (или решили менять), можно вызвать REST: PUT /rest/api/2/project/{projectId} с полем "permissionScheme": <id>, аналогичного для уведомлений – такой REST может существовать (например, Jira has some project update endpoint). Если нет – опять же Java API (ProjectManager.updateProject).

    • Automation rules: сообщить администратору, что правила нужно настроить вручную, или если предусмотрена какая-то автологика, то возможно создать ScriptRunner Listener на событие "ProjectCreatedEvent" – и в нём программно добавлять нужные правила (но это уже очень сложно, т.к. нет API).

Этот REST-ориентированный подход может стать сложным, если требуется много кастомизации. Каждый шаг – отдельный вызов, нужно обрабатывать ошибки, задержки (например, ждать, когда Jira действительно создаст проект и новые схемы доступны). Кроме того, часть задач (workflow, issue types) вообще нельзя выполнить через REST, и их придётся либо исключить (т.е. использовать только заранее существующие компоненты), либо реализовать обходные пути.

2. Глубокая интеграция через ScriptRunner/плагин: В этом варианте бэкенд напрямую не дергает десятки REST Jira, вместо этого он вызывает свой серверный код внутри Jira, который уже сделает всё необходимое. Практическая реализация:

  • ScriptRunner REST Endpoint: написать Groovy-скрипт, принимающий JSON с параметрами (тип проекта, ключ, схемы и пр.). Этот скрипт, выполняясь на стороне Jira, получит через API Jira необходимые менеджеры и выполнит:

    1. Валидацию входных данных (например, нет ли конфликта ключей, существуют ли упомянутые типы задач и т.д.).

    2. Создание проекта через ProjectService. Этот метод сразу позволяет указать базовые схемы (или указать флаг создавать их автоматически). Получаем объект проекта и его ID.

    3. Если нужны новые элементы:

      • Если выбран нестандартный набор issue types: скрипт может через IssueTypeSchemeManager сформировать новую схему, добавить нужные типы (из глобально существующих) и прикрепить к проекту.

      • Если нужны уникальные workflow: скрипт может взять базовый workflow (например, “Workflow шаблон”) и через WorkflowManager склонировать его под новым именем, затем отредактировать — добавить/удалить статусы, переходы. (Прямое создание с нуля – возможно, но сложнее; эффективнее заранее иметь библиотеку шаблонов, которые комбинируются). После этого через WorkflowSchemeManager создать новую схему workflow, привязать workflow к нужным Issue Type и присвоить проекту.

      • Создать нужные Custom Fields (CustomFieldManager.createCustomField) – если они глобальные, либо связать с контекстом проекта (в Jira custom field context можно ограничивать проектами/типами).

      • Привязать поля к экранам: найти Screen Scheme проекта (FieldScreenSchemeManager), достать экраны (Screen) и добавить поля через FieldScreenLayoutManager.

      • Если нужны новые Statuses (статусы глобальны для всей Jira): через ConstantsManager можно добавить статус (в Jira это сохранится глобально). Но добавлять множество статусов программно нужно осторожно, чтобы не замусорить глобальный список.

      • Назначить существующие Permission Scheme и Notification Scheme: через ProjectManager.updateProject(project, ProjectUpdateParameters) или соответствующие сервисы поменять привязки схем.

      • Создать Components, Versions и другие атрибуты, если это тоже входит в шаблон (это уже проще – для них есть REST, но можно и Java API).

      • Automation Rules: как отмечалось, придётся пропустить или решить вне Jira. Либо скриптом сразу создавать нужные Listeners/Post-functions вместо automation.

    4. Вернуть результат выполнения (успех/неуспех, детали созданного проекта) наружу.

Собственный плагин: альтернатива ScriptRunner – реализовать всё то же на Java в плагине. Плагин может экспонировать REST endpoint (через JAX-RS), который будет вызван внешним UI. Логика внутри – такая же: использование сервисов Jira. Разница лишь в том, что код пишется на Java и деплоится как дополнение. Это дает больше контроля (например, транзакции, own UI in Jira if needed), но и требует большего времени разработки. Если ScriptRunner уже доступен, он сильно ускоряет процесс за счёт динамичности.

Этот подход с внутренним кодом более сложен в разработке, но закрывает все пробелы REST API, т.к. использует те же возможности, что и ручная настройка. Atlassian фактически рекомендует такой путь для полной автоматизации​. К тому же, такой скрипт/плагин можно отладить и убедиться, что создаётся корректная конфигурация, прежде чем открывать внешний доступ.

  • Хранение шаблонов: Независимо от подхода, стоит продумать, как будут определяться возможные конфигурации. Например, можно заранее создать несколько “эталонных” наборов (типы задач + workflow + поля) и просто позволять пользователю выбирать между ними в UI (выпадающий список "Тип проекта"). Тогда задача скрипта упрощается: по выбранному типу решается, какие схемы использовать или какие шаги выполнить. В противном случае, если UI позволяет произвольную комбинацию, скрипт должен быть очень гибким и готовым создавать новые комбинации на лету (что увеличивает сложность и риск ошибок).

  • Права доступа: Внешний UI может быть доступен ограниченному кругу (например, только админы или пользователи-менеджеры). Но сам бекенд всё равно выполняется с админскими правами. Желательно, чтобы внешнее приложение не хранило прямой пароль администратора. Более безопасно использовать либо API Token (если Jira DC поддерживает PAT в REST), либо OAuth (впрочем, для Jira Server/DC обычно используют Basic Auth от сервисного аккаунта). Если используется ScriptRunner endpoint, можно ограничить его использование токеном или проверять, что вызвавший – админ.

  • Обработка ошибок и ограничений: Нужно учесть кейсы, когда какая-то часть конфигурации не может быть создана. Например, попытка создать проект с ключом, который уже занят – Jira вернёт ошибку (REST даст 400 Bad Request). Или попытка создать custom field с именем, которое уже используется. Бэкенд должен грамотно обработать и сообщить об этом пользователю UI. Также возможно, какие-то вещи требуют перезапуска Jira (например, новый статус появится в UI сразу, но если меняется плагин – потребуется рестарт). Стараться избегать того, что не может применяться на горячую.

Пример последовательности (pipeline):

  1. Пользователь заполняет форму (назовём его template form) и нажимает "Создать проект".

  2. Бэкенд (например, веб-сервис) получает JSON с параметрами.

  3. Бэкенд вызывает Jira:

    • Если используется ScriptRunner: выполняется один вызов на кастомный REST endpoint Jira, передающий весь JSON.

    • Если чистый REST: выполняется ряд вызовов (создать проект, создать поле, добавить поле и т.д.). При любой ошибке дальнейшие шаги, возможно, откатываются вручную (например, удалить уже созданный проект, если последующий шаг провалился).

  4. Jira создаёт проект и настраивает его. Например, ScriptRunner-скрипт последовательно:

    • Создаёт проект (через API).

    • Применяет схемы (workflow, issue types, etc.) – либо существующие, либо новые.

    • Создаёт и размещает нужные поля.

    • Настраивает права и уведомления.

  5. Бэкенд получает подтверждение (например, ID нового проекта или ошибку).

  6. Внешний UI уведомляет пользователя о результате: либо проект успешно создан (с ссылкой на него), либо выдает сообщение об ошибке с деталями.

При успешном выполнении администратор сможет сразу использовать новый проект. Если что-то было не автоматизировано (например, правила автоматизации), админ после создания может вручную доналаштровать эти элементы.

Заключение: Полностью кастомное создание проектов Jira – реализуемо, но требует комбинации подходов. Простые случаи покрываются вызовом стандартного REST с правильными шаблонами (и это предпочтительно для снижения сложности). Для гибкой настройки на лету необходим либо ScriptRunner/плагин с доступом к Jira API, либо опора на заранее сконфигурированные шаблоны (которые копируются через createshared)​. В архитектуре решения важно чётко определить, какие части будут “жёстко” зашиты (предсозданы) в Jira, а какие – генерироваться по запросу. Оптимальным на практике может быть компромисс: иметь несколько подготовленных вариантов (workflow, схемы и т.п.), и комбинировать их программно, вместо создания всего с нуля для каждого проекта. Это снизит сложность и вероятность ошибок при внедрении внешнего автоматизированного UI для создания проектов.