How to lock Jira issues based on workflow status
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Jira administrators and project leads may find it helpful to lock specific Jira issues based on workflow status. This is useful for creating "template" issues that users can clone – or for archiving closed issues.
Solution
Instructions
Define your editor group
Decide who can create and edit templates or reopen closed issues. You can create a global group (such as template-editor) or define a new project role. For more info, check out View, create, or delete a group or Managing project roles.
Project role ID
If you decide to use a project role, you'll need to note its ID number for a later step. From the project roles admin page, click edit next to your desired group. Your browser URL will end with EditProjectRole!default.jspa?id=10002 , where 10002 is the project role ID.
Create a status/workflow step
Choose which status you'd like to use for locked issues. For example, you may name this Template or Closed. Add this status as a step to your workflow and create at least one incoming and outgoing transition.
Restrict the transition
To limit who can create templates, add a User Is In Group or User Is In Project Role condition to the incoming transition and set it to the group/role previously created. If your goal is to lock closed issues, set the condition on the outgoing transition(s).
Add workflow step properties
To access the workflow step properties:
Open the workflow designer (diagram tab).
Select the template/locked step.
Click the blue properties link.
Add the following properties:
Key | Value | Description |
|---|---|---|
|
| Primary toggle for disabling editing. This key is the only way to disallow certain operations, such as creating sub-tasks. Note: permission grants do not override this key. |
| [blank] | Revoke the "edit issue" permission. |
| [blank] | Revoke the "transition issue" permission. |
| [blank] | Revoke the "move issue" permission. |
| [blank] | Revoke the "comment" permission. |
| [blank] | Revoke the "manage watchers" permission. |
| [blank] | Revoke the "view voters and watchers" permission. |
Group j
|
| If your editors are defined by a global group, replace |
Role
|
| If your editors are defined by a project role, replace |
Apply changes
Save this workflow and associate it with a workflow scheme used by the desired project(s). Add users to your global group or assign users your new project role.
Jira administrators
Jira administrators don't automatically inherit the editor permissions, so you'll need to add these users to your editor group or make your Jira admin group a second editor group.
Convert an issue into a template
As a user in your editor group/role, navigate to an issue you'd like to convert into a template. Select your new status from the transition dropdown.
Troubleshooting
Don't see your transition? Confirm that:
You've saved and published your workflow.
The workflow is associated with a workflow scheme.
The current project uses that workflow scheme.
This issue's type uses the template workflow, as defined in the workflow scheme.
There's a transition to the template status from the current status.
The current user is in the editor group or assigned the editor role.
If you get an error 500 message while loading an issue using this workflow, then you've entered an invalid property key or value. Check the atlassian-jira.log file for more details.
(Optional) Make additional changes
If a user with template editor permission needs to modify the issue, they must first transition it back to an unlocked status. After making the necessary changes, they can transition back to the locked status.
Further customization
Technical background
Workflow steps (statuses) can contain custom properties, including issue permission overrides. This behavior is outlined on Workflow properties.
All available permissions
All standard (Jira Core) project permissions are applicable, even if they have no effect on an individual issue. Third-party, Jira Software, and Jira Service Management-specific permissions are not supported.
Key | Short Name |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All available users and user groups
You can replace the group or user in the permission overrides with any of the following:
Key | Description |
|---|---|
group | A user group – specify group name as value |
projectrole | A user role – specify role ID as value |
user | A user – specify username as value |
assignee | The issue assignee |
reporter | The issue reporter |
lead | The issue's project lead |
userCF | A user custom field – specify CF ID (customfield_XXX) as value |
groupCF | A group custom field – specify CF ID (customfield_XXX) as value |
Formatting and considerations
The format for permission overrides is:
1
jira.permission.[subtasks].<permission>.[group|user|...].[1|2|3|...].[denied]If you need to specify multiple target user groupings, use
.1for the first,.2for the second, and so on. For example: setjira.permission.transition.group.1togroup-name.Use the
subtasksclause to specify subtasks of the issue currently in this workflow step.
Was this helpful?