Use workflow properties

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

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

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

jira.permission.*.denied

Using the jira.permission property, you can further restrict an action altogether by using denied for the {user}.

Examples

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

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