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.
In this case, when users responding to closed issues via email it will create a new ticket instead of create a new comment.

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 = account-id

  • 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:

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:

  1. Login as a Project Administrator;
  2. Go to Project settings > Workflows;
  3. Select an active workflow;
  4. Navigate to the step which needs to be modified;
  5. 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.