• Products
  • Documentation
  • Resources

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

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:

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

jira.permission.modifyreporter.user

accountId e.g. 5d8c5b7dc26b6a0dcb0cec44

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 adding comments when an issue 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 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 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 issues across your site.

By default, workflow status categories appear on issues 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

opsbar-sequence

0

Place a status transition category at the bottom of the list that includes five total categories

opsbar-sequence

4

Why isn’t this “5”?
Because the entry at the top of the list is numbered 0.

Still need help?

The Atlassian Community is here for you.