Starting with JIRA 6.4 and completed in JIRA 7.0, the underlying default behavior of JIRA has changed in a number of significant ways related to projects. This will likely negatively impact your project creation automation unless you make some changes. The CLI has attempted to remedy this situation especially with CLI 6.1 support.
Shared Schemes No Longer the Default
Using shared schemes has been the default JIRA behavior since the inception of JIRA. However, Atlassian has been moving to project specific schemes instead. While there were some changes started in JIRA 6.4, the CLI made efforts to mitigate incompatibilities by choosing to use the JIRA Classic Template by default. The classic template used the shared project schemes. However, this template was removed in JIRA 7.0 and the CLI can no longer mask the incompatibility. The CLI will follow the JIRA 7.0 defaults for project creation. If you want to continue to use shared schemes, you must explicitly request that. However, this only works for the schemes that JIRA allows us to specify on the create project API (issue security, permission, and notification schemes) - Atlassian is planning for expanded support in this area in the future. For example:
--action createProject --issueTypeScheme "Default Issue Type Scheme" --issueTypeScreenScheme "Default Issue Type Screen Scheme" --permissionScheme "Default Permission Scheme"
For workflow, consider creating a classic workflow scheme and associating the the jira classic workflow. Then the project creation action would become:
--action createProject --workflowScheme classic --issueTypeScheme "Default Issue Type Scheme" --issueTypeScreenScheme "Default Issue Type Screen Scheme" --permissionScheme "Default Permission Scheme"
Shared Schemes Returns
Starting with JCLI 6.1, the cloneProject action will now create a project with a shared configuration just like the UI option for this. See
JCLI-349Getting issue details...
. More over, even on the createProject action you can get a shared configuration by referencing an existing project via the template parameter. See
JCLI-1055Getting issue details...
for more details. When a create or clone is done in this way, JIRA will not create extraneous and unwanted project specific schemes. Here is an excerpt from JCLI-1055:
cloneProject will now create the clone using the "shared configuration" option shown on the UI. This means schemes will be the same as the base project unless specifically overridden. The old behavior that involved creating project specific schemes will no longer be an option (create an issue if you need this behavior resurrected). While this is an incompatibility, this new behavior is more the expected behavior from a clone operation.
JIRA 7.x has renamed a number of templates and removed some (like the JIRA Classic Template). Also, if you built private templates via the JIRA plugin exit point, that has also changed in an incompatible way and will need to be redone.
With release 5.1
, we have added more actions related to deleting constructs like schemes especially since many of these things are automatically created with JIRA 7.x and often not needed.
- JCLI-814Actions to manage and delete schemes and related constructs CLOSED
has more on this.
For more information on actions, see the action Reference.
For these actions, use an automation user id who's language is English. This is necessary since JIRA doesn't yet provide language neutral REST APIs for retrieving this information.