Workflow properties

Jira’s workflow properties let you set restrictions on certain steps or transitions of a workflow. Thus, the issue view can be modified depending on the issue status in the workflow.

In this document, you’ll learn about:

We don’t recommend using all of the available workflow properties because we can’t guarantee that some data and operations, like bulk operations, won’t be corrupted.

For details on how to set properties in a workflow, see Working with workflows.

Jira workflow properties

The following table lists workflow properties you can use in a transition or step of a workflow. Check the API documentation for more technical details: Jira API Documentation - JiraWorkflow constant values

The names of Jira’s workflow properties start with the prefix jira. If you have third-party apps installed on the instance, they might introduce custom properties. If a property doesn’t start with jira, this is a third-party property. To learn more about it, reference the app’s documentation.

NameDescriptionRelated
issues
References

jira.field.
resolution.
exclude

Value: Resolution id

Allows you to add comma-separated resolution IDs to the transition properties where you don’t want to show particular resolutions.N/AN/A

jira.field.
resolution.
include

Value: Resolution id

Allows you to add comma-separated resolution IDs to the transition properties.JRA-16443N/A

jira.i18n.
submit

Value: I18n property key

The transition property that allows you to customize the name of a button on a screen.JRA-16443N/A

jira.i18n.
title

Value: I18n property key

The transition property that allows you to customize the description of a button on a screen. You can see this description when you hover over the button.JRA-6798N/A

jira.i18n.
description

Value: I18n property key

The transition property that allows you to customize the description of a workflow transition.JRA-6798N/A

jira.issue.
editable

Value: true, false

The step property that restricts field editing and sub-tasks creation in issues.N/AWorking with workflows

jira.
permission
[.S].X.Y

Value:

  • A target user, group,
    or project role of
    the permission

  • denied if you want
    to deny all users

Details

X is the permission and Y is the target.

X is one of the following:
browse, edit, transition, move, assignable, assign, resolve, delete, link, setsecurity, comment,
attach, work.

For Y, use denied to deny
all users or use one of the
following: group, user,
assignee, reporter,
lead, userCF, groupCF, projectrole.

.S is optional for applying
subtasks to target subtasks
of a parent issue.

The number can be added to
specify the multiple of the
same X and Y.

The step property that restricts
the permission to a subset of users or to all users.

Examples
  • Allow test users to edit
    issues: jira.permission.
    edit.user=test-user

  • Allow comments from the groups jupiter and mars: jira.permission.
    comment.group.
    1=jupiterjira.

    permission.
    comment.group.2=mars

  • Deny the permission to attach files for everyone:
    jira.permission.
    attach.denied=denied

  • Only allow a group specified in the custom field to assign issues:
    jira.permission.
    assign.groupCF=
    customfield_
    11000

  • Only allow Jira admins to edit issues:
    jira.permission.
    edit.group=jira-administrators

JRA-6381

JRA-34621

JRA-35917

WorkflowBased
PermissionManager
class description (API documentation)

opsbar-
sequence

Value: Integer value greater
than or equal to 0

Allows transitions on the View Issue page.N/AAdvanced workflow configuration (Customizing transitions)

Use cases

Check the use cases of how some of the workflow properties can be applied.

PropertyUse caseUse case value
jira.field.
resolution.
exclude

Disable a particular resolution for a particular status. For example, to make the Duplicate resolution unavailable for a status.

Important note

You should use the ID of the resolution instead of the name. To find the resolution ID:

  1. In the upper-right corner of the screen, select Administration Issues.
  2. Under Issue attributes, select Resolutions.
  3. Select Edit next to the resolution for which you want to get the ID.
  4. You’ll see the ID in the URL after ?. For example: id=10000 for Done.

A list of comma-separated IDs of the resolutions to exclude. For example: "10000,10001".

Add multiple resolutions to the property

To do this, you should add a list of resolution IDs, separated by commas.

For example, if you want to exclude the resolutions with the IDs 10000 and 10001, you should set the value "10000,10001".

jira.field.
resolution.
include
Enable a particular resolution for a particular status. For example, to enable the Duplicate resolution for a status.

A list of comma-separated IDs of the resolutions to include. For example: "10000,10001".

To add multiple resolutions to the property, check the instruction above.

jira.issue.
editable

Make an issue editable when it has a particular status. By default, if this property isn’t set, issues are always editable.

true
Disable editing when an issue has a particular status. This may be helpful when the issue is at the final stage of the process and has some of the finalizing statuses like Done.false
jira.
permission
[.S].X.

Use this property in the following format: jira.permission.
[subtasks.]{permission}.
{user}.{suffix}
.

Important note

Use these workflow permissions only to locally restrict permissions set in a permission scheme, and not to grant permissions.

For example, if the permission scheme has the Add comments permission granted to only one project role (for example, Developers), you can't use the workflow properties to grant this permission to other roles (Managers).

If the Managers role is excluded from the permission scheme, adding this role to the workflow property won’t work.

  • subtasks is optional. If you add this part, the permission will be applied to an issue's subtasks. If not, the permission will be applied to the issue itself.

  • permission is a short name specified in the Permissions class.

  • user is the type of the permission granted or denied.

  • suffix is optional. Use it to make the property unique when you have the same type added more than once. 
    For example, jira.permission.edit.
    group.1
    , jira.permission.edit.
    group.2
    .
With permission, the following values can be used

admin, use, sysadmin,
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

With user, the following values can be used

group, user, assignee, reporter, lead, userCF, projectrole

jira.
permission.*
.denied

jira.permission.
edit.denied disables issue
editing for all users, including
admins, when an issue has a
particular status.

Must be empty
jira.permission.
work.denied
disables
work log when an issue
has a particular status.
This is helpful to add to
statuses of epics.
Must be empty

jira.permission.
attach.denied
disables
new attachments for issues in
a particular status. For example,
if you want users to add
attachments only when the
the issue has the status
In
Progress
, add this property to every status except In
Progress
.

You can set this property for all workflow statuses but allow only particular users to create attachments by giving them the Create attachment permission. This provides protection against anonymous users or attackers attaching large files to the system, which may bring Jira down after the disk space runs out.

Must be empty

jira.permission.
comment.denied
disables
comments when an issue has a particular status. For example,
you can add this property to a resolution status if you don't
want users to comment after
an issue has been closed.

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

Must be empty

Setting a workflow property

To add a workflow step or transition property:

  1. Go to Administration > Issues.

  2. In the left panel, select Workflows.

  3. For a workflow where you want to set a property, select Edit.

  4. Select a status or transition you want to add a property for.

  5. In the menu, select Properties.

  6. You’ll be brought to a page where you should enter the key and value of a property.

  7. Select Add.



Last modified on Mar 2, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.