How to lock Jira issues based on workflow status
Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.
Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles 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.
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 |
---|---|---|
jira.issue.editable | false | 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. |
jira.permission.edit.denied | [blank] | Revoke the "edit issue" permission. |
jira.permission.transition.denied | [blank] | Revoke the "transition issue" permission. |
jira.permission.move.denied | [blank] | Revoke the "move issue" permission. |
jira.permission.comment.denied | [blank] | Revoke the "comment" permission. |
jira.permission. | [blank] | Revoke the "manage watchers" permission. |
jira.permission. | [blank] | Revoke the "view voters and watchers" permission. |
GROUP jira.permission. | template-editors | If your editors are defined by a global group, replace template-editors with your group name. |
ROLE jira.permission. | 10002 | If your editors are defined by a project role, replace 10002 with your role ID. |
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.
Formatting and considerations
The format for permission overrides is:
jira.permission.[subtasks].<permission>.[group|user|...].[1|2|3|...].[denied]
- If you need to specify multiple target user groupings, use
.1
for the first,.2
for the second, and so on. For example: setjira.permission.transition.group.1
togroup-name
. - Use the
subtasks
clause to specify subtasks of the issue currently in this workflow step.