• Products
  • Documentation
  • Resources

Use workflow properties

You can use workflow properties to add restrictions on workflow transitions.

Some of the workflow properties on this page may cause bugs. If something breaks after adding a property, try removing it.

Available Jira workflow properties

jira.field.resolution.include and jira.field.resolution.exclude

If you don’t want a particular resolution to be available on an issue 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 status

For example, if you want to enable the “Duplicate” resolution on a status.

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 status. This will make the resolution unavailable.

jira.field.resolution.exclude

(resolution IDs separated by comma)

jira.issue.editable

You may not want an issue to be editable when it’s on a particular status. For example, once an issue 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 an issue editable when it's on a particular status.

jira.issue.editable

true

To disable editing when an issue 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 an issue’s subtasks.

  • {permission} is the permission you want to restrict. The available permissions are:

    • browse, viewversioncontrol, viewworkflowreadonly, create, edit, transition, scheduleissue, move, assignable, assign, resolve, close, modifyreporter, delete, link, setsecurity, viewvotersandwatchers, managewatcherlist, commenteditall, commentdeleteall, commentdeleteown, comment, attachdeleteall, attachdeleteown, attach, worklogeditown, worklogeditall, worklogdeleteall, work.

  • {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 an issue and its subtasks when an issue is on a particular status

jira.permission.subtasks.attachdeleteown.group

 

 

jira-group-developers

Only allow user123 to modify the reporter when the issue on a particular status

jira.permission.modifyreporter.user

user123

Only allow the reporter to transition the issue 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 an issue

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 an issue is on a particular status, for all users including admins.

jira.permission.edit.denied

(leave empty)

To disable work log when an issue is on a particular status. Often added to statuses on Epics.

jira.permission.work.denied

(leave empty)

To disable adding new attachments when an issue is on a particular status. For example, if you only want people adding attachments when the issue is In Progress, add this property to every other status.

jira.permission.attach.denied

(leave empty)

To disable comments when an issue is on a particular status. For example, you can add this to a resolution status if you don’t want people commenting after you’re done with an issue.

When comments are disabled completely, they’re not available on transition screens.

jira.permission.comment.denied

(leave empty)

 

Additional Help