How to lock Jira issues based on workflow status

Still need help?

The Atlassian Community is here for you.

Ask the community

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:

  1. Open the workflow designer (diagram tab).
  2. Select the template/locked step.
  3. Click the blue properties link.

Add the following properties:

KeyValueDescription
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.
managewatcherlist.denied
[blank]Revoke the "manage watchers" permission.
jira.permission.
viewvotersandwatchers.denied
[blank]Revoke the "view voters and watchers" permission.
GROUP jira.permission.
transition.group
template-editors
If your editors are defined by a global group, replace template-editors with your group name.
ROLE jira.permission.
transition.projectrole
10002If 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:

  1. You've saved and published your workflow.
  2. The workflow is associated with a workflow scheme.
  3. The current project uses that workflow scheme.
  4. This issue's type uses the template workflow, as defined in the workflow scheme.
  5. There's a transition to the template status from the current status.
  6. 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.

KeyShort Name
ADMINISTER_PROJECTS
project
BROWSE_PROJECTS
browse
VIEW_DEV_TOOLS
viewversioncontrol
VIEW_READONLY_WORKFLOW
viewworkflowreadonly
CREATE_ISSUES
create
EDIT_ISSUES
edit
TRANSITION_ISSUES
transition
SCHEDULE_ISSUES
scheduleissue
MOVE_ISSUES
move
ASSIGNABLE_USER
assignable
ASSIGN_ISSUES
assign
RESOLVE_ISSUES
resolve
CLOSE_ISSUES
close
MODIFY_REPORTER
modifyreporter
DELETE_ISSUES
delete
LINK_ISSUES
link
SET_ISSUE_SECURITY
setsecurity
VIEW_VOTERS_AND_WATCHERS
viewvotersandwatchers
MANAGE_WATCHERS
managewatcherlist
EDIT_ALL_COMMENTS
commenteditall
EDIT_OWN_COMMENTS
commenteditown
DELETE_ALL_COMMENTS
commentdeleteall
DELETE_OWN_COMMENTS
commentdeleteown
ADD_COMMENTS
comment
DELETE_ALL_ATTACHMENTS
attachdeleteall
DELETE_OWN_ATTACHMENTS
attachdeleteown
CREATE_ATTACHMENTS
attach
EDIT_OWN_WORKLOGS
worklogeditown
EDIT_ALL_WORKLOGS
worklogeditall
DELETE_OWN_WORKLOGS
worklogdeleteown
DELETE_ALL_WORKLOGS
worklogdeleteall
WORK_ON_ISSUES
work
All available users and user groups

You can replace the group  or user in the permission overrides with any of the following:

KeyDescription
groupA user group – specify group name as value
projectroleA user role – specify role ID as value
userA user – specify username as value
assigneeThe issue assignee
reporterThe issue reporter
leadThe issue's project lead
userCFA user custom field – specify CF ID (customfield_XXX) as value
groupCFA group custom field – specify CF ID (customfield_XXX) as value

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: set jira.permission.transition.group.1 to group-name.
  • Use the subtasks clause to specify subtasks of the issue currently in this workflow step.


Last modified on Dec 5, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.