Useful workflow properties for Jira Cloud
You can use workflow properties to implement restrictions on functions and certain steps or transitions of a workflow.
Not everything on this page is recommended
We don't recommend using all of these types of workflow properties as we can't guarantee that some data and operations (like bulk operations) won't break. Use these types of workflow properties at your own risk.
Jira gives us a big set of options to restrict many of the operations(as comment, edit) on issues depending on the issue status.
If you need to enforce a particular permission check at any status in the workflow, you must add the jira.permission. property on the workflow transition.
Note that workflow permissions can only restrict permissions set in the permission scheme, not grant permissions.
Example:
Sometimes you need to restrict users to leave a new comment on closed tickets. For this scenario, you can use the property below to perform this action:
Use case | Key | Value |
|---|---|---|
The comment feature is disabled at this state. This property will restrict users leaving a new comment after the tickets getting closed. | jira.permission.comment.denied | (EMPTY) |
Permission - a short name specified in permissions section. Following are the allowed values for Jira Cloud:
admin, user, project, browse, create, edit, scheduleissue, assign, assignable, attach, resolve, close, comment, delete, work, worklogdeleteall, worklogdeleteown, worklogeditall, worklogeditown, link, sharefilters, groupsubscriptions, move, setsecurity, pickusers, viewversioncontrol, modifyreporter, viewvotersandwatchers, managewatcherlist, bulkchange, commenteditall, commenteditown, commentdeleteall, commentdeleteown, attachdeleteall, attachdeleteown, viewworkflowreadonly
Type - type of permission granted/denied. The values can be empty(when the property is already revoking the permission with .denied), true/false, user, assignee, reporter, projectrole, or group.
Suffix - An optional suffix to make the property unique when you have the same type added more than once! jira.permission.edit.group.1, jira.permission.edit.group.2 etc
Enter the appropriate value in the Property Value field. If the type is a group, enter a group. If its an user, then enter a user name and so on.
A few interesting examples below:
jira.permission.comment.group = some-group
jira.permission.comment.denied =
jira.permission.edit.group.1 = some-group-one
jira.permission.edit.group.2 = some-group-two
jira.permission.modifyreporter.user = username
jira.permission.delete.projectrole = 10000
jira.permission.subtasks.delete.projectrole = 10000
You can even use the value as denied when the type is not used.
Not everything on this page is recommended
If you're already using a property to deny any function in Jira, and add a different property denying the same function, the result will be null and the function will work normally.
Available Jira workflow properties
There are a few workflow properties which you can use in a transition or step of a workflow. Take a look at the Workflows section of the Jira Cloud REST API documentation for more.
jira.field.resolution.exclude
Accepted values: Resolution ID. Add comma-separated resolution IDs to the transition properties where you want to not show certain resolutions.
jira.field.resolution.include
Accepted values: Resolution IDs. Add comma-separated resolution IDs to the transition properties where you do want to show certain resolutions.
jira.i18n.submit
Accepted values: i18n property key. Transition (usage: action submit button name).
Feature Request Related: JRACLOUD-6798 - Getting issue details... STATUS
jira.i18n.title
Accepted values: i18n property key. Transition (usage: action name, etc.).
Feature Request Related: JRACLOUD-6798 - Getting issue details... STATUS
jira.issue.editable
Accepted values: true, false. Step. See Working with workflows.
jira.permission.*
Accepted values: user, group and roles. Step (usage: only to restrict permission to either roles, group, or users when issue is in that step).
See:
- Permissions based on Workflow Status
- For link permissions
jira.permission.edit.group=jira-administratorsmeans that only Jira administrators can edit an issue (blog)- REST API permissions
Related Bug: JRACLOUD-35917 - Getting issue details... STATUS - Closed as timed out
jira.permission.work.denied
Accepted value: denied. To prevent users from logging work when the issue transitions to a specific status and disallow users from editing or deleting work log in activity tab. See How to restrict Log Work on a specific status.
opsbar-sequence
Accepted values: Integer value greater than or equal to 0. Transitions on the 'View Issue' screen. See Advanced workflow configuration (Customizing transitions).
How to add/edit a workflow property and perform a restriction:
- Login as a Project Administrator;
- Go to Project settings > Workflows;
- Select an active workflow;
- Navigate to the step which needs to be modified;
- Click on the View step's properties link;
If you cannot set and publish the changes in your workflow, then associate the workflow with the appropriate scheme before.
When a particular permission property is linked to a workflow status, Jira enforces the same.
You can also view more information about this subject at > Use workflow properties.
For more details on how to implement workflow properties(step and transition properties) in your workflow, please refer to Working with workflows.