Use workflow properties
You can use workflow properties to add restrictions on workflow statuses and transitions.
Some of the workflow properties on this page may cause bugs. If something breaks after adding a property, try removing it.
Status properties
jira.issue.editable
‘Issue’ refers to ‘work item’. What is a work item?
You may not want a work item to be editable when it’s on a particular status. For example, once a work item is in a “Done” status, you may want to restrict editing to ensure no data changes after work is completed.
Examples
Use case | Key | Value |
|---|---|---|
To make a work item editable when it's on a particular status. | jira.issue.editable | true |
To disable editing when a work item is on a particular status. Often used on a final status. | jira.issue.editable | false |
jira.permission.*
If you want to enforce restrictions beyond the permission scheme, you can do so with the jira.permission workflow property. Using this permission, you can restrict certain actions to the users of your choice.
The format of the jira.permission.* workflow property is jira.permission.[subtasks.]{permission}.{user}.[.suffix].
jira.permission to start the property.
[subtasks.] is optional and applies the permission restriction to a work item’s subtasks.
{permission} is the permission you want to restrict. The available permissions are:
viewversioncontrol, viewworkflowreadonly, create, edit, transition, scheduleissue, move, assignable, assign, resolve, close, modifyreporter, delete, link, setsecurity, viewvotersandwatchers, managewatcherlist, commenteditall, commenteditown, commentdeleteall, commentdeleteown, comment, attachdeleteall, attachdeleteown, attach, worklogeditown, worklogeditall, worklogdeleteall, work. Read about different project permissions
{user} is who’re restricting the permission to — applicationRole, assignee, reporter, sd.customer.portal.only, groupCF, group, lead, projectrole, user, userCF.
[.suffix] is an optional number used to add the same property more than once.
Examples
Use case | Key | Value |
|---|---|---|
Only allow people who are part of jira-group-developers to delete all attachments on a work item and its subtasks when a work item is on a particular status | jira.permission.subtasks.attachdeleteown.group
| groupId e.g. 8ed46c45-d74a-40a0-983f-837391c749fb |
Only allow user123 to modify the reporter when the work item on a particular status | jira.permission.modifyreporter.user | accountId e.g. 5d8c5b7dc26b6a0dcb0cec44 |
Only allow the reporter to transition the work item when it’s on a particular status | jira.permission.transition.reporter | (leave empty) |
Only allow a user who has the projectRoleId of 2 to comment on a work item | jira.permission.comment.projectrole | 2 |
jira.permission.*.denied
Using the jira.permission property, you can further restrict an action altogether by using denied for the {user}.
Examples
Use case | Key | Value |
|---|---|---|
To disable editing when a work item is on a particular status, for all users including admins. | jira.permission.edit.denied | (leave empty) |
To disable work log when a work item is on a particular status. Often added to statuses on Epics. | jira.permission.work.denied | (leave empty) |
To disable adding new attachments when a work item is on a particular status. For example, if you only want people adding attachments when the work item is In Progress, add this property to every other status. | jira.permission.attach.denied | (leave empty) |
To disable adding comments when a work item is on a particular status. When adding comments is disabled, they're not available on transition screens. | jira.permission.comment.denied | (leave empty) |
Transition properties
jira.field.resolution.include and jira.field.resolution.exclude
If you don’t want a particular resolution to be available on a work item while it’s on a particular status, you can use the jira.field.resolution property to restrict it.
Examples
Use case | Key | Value |
|---|---|---|
Enable a particular resolution on a transition For example, if you want to enable the “Duplicate” resolution on a transition. | jira.field.resolution.include | (resolution IDs separated by comma) |
Disable a particular resolution on a status For example, if you want to disable the “Duplicate” resolution on a transition. This will make the resolution unavailable. | jira.field.resolution.exclude | (resolution IDs separated by comma) |
opsbar-sequence
The opsbar-sequence function allows you to change the order in which workflow status categories appear on work items across your site.
By default, workflow status categories appear on work items in the following order: To do, In progress, then Done. This property allows you to individually reorder transitions by adding a value to the Property value field. When sequencing transitions, those with the lowest number are sorted first, starting from 0.
Transitions with this property are prioritized at the top of the menu; all other transitions (without this property) show beneath it and are sorted using the standard logic referenced above.
Examples
Use case | Key | Property value |
|---|---|---|
Place a status transition category at the top of the list |
| 0 |
Place a status transition category at the bottom of the list that includes five total categories |
| 4 Why isn’t this “5”? |
Was this helpful?