Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

You can use workflow properties to implement restrictions on certain steps or transitions of a workflow (below).

(minus) Please Note: Not everything on this page is recommended!

  • We do not recommend using all of these types of workflow properties as we cannot guarantee that some data and operations (e.g. bulk operations) will not be broken. Hence, use these types of workflow properties at your own risk!

(info) For details on how to implement workflow properties (i.e. step and transition properties) in your workflow, please refer to Configuring Workflow.

Available JIRA workflow properties

There are a few workflow properties which you can use in a transition or step of a workflow. Here are some helpful links:

Name

Values

Related Issues

References

Notes

jira.field.resolution.exclude

Resolution id

 

Resolutions per workflow step

Add comma-separated resolution ids to the transition properties where you want to not show certain resolutions

jira.field.resolution.include

Resolution id

JRA-16443

Resolutions per workflow step

Add comma-separated resolution ids to the transition properties

jira.i18n.submit

i18n property key

JRA-6798

 

Transition (usage: action submit button name)

jira.i18n.title

i18n property key

JRA-6798

 

Transition (usage: action name, etc.)

jira.issue.editable

true, false

 

Configuring Workflow

Step

jira.permission.*

user1, user2 / group1, group2 / role/

...?

 

JRA-6381

JRA-34621

JRA-35917

Step (usage: only to restrict permission to either roles,group, or users when issue is in that step)

 

opsbar-sequence

Integer value greater than or equal to 0

 

Configuring Workflow (Customizing Transitions)

Transitions on the 'View Issue' page

  • No labels

38 Comments

  1. I just tried adding a comment permission restriction to a workflow state in 3.6.5 jira.permission.comment.user  and it works fine. I then tried doing a builk operation to transfer a couple of issues to another workflow state and didn't get any errors. Does anybody know what areas of bulk operations actually break as per the warning above?

    Has anyone else experienced bulk change errors when implementing these permissions?

    1. Hi Ben,

      I have just tested two workflow properties on bulk operation:

      • jira.permission.assignable.user
      • jira.permission.close.user

      And they worked fine. Perhaps this page needs an update.. I'll follow up this anyway.

      Cheers,
      Yuen-Chi

  2. Where is the list of possible "values" for each of the properties and a description of what they do?

    E.g. Where does it show that you can set jira.issue.editable = false

    I've seen the constant values API documentation but it only shows the permission name but not what possible values it can hold. There is also no description of what each of the properties does?

  3. Your documentation for jira.permission.* give me the following "wrong" information:

    The format is 'jira.permission.[subtasks.]

    Unknown macro: {permission}

    .

    Unknown macro: {type}

    [.suffix]', where:

    is a short name specified in Permissions

    • Unknown macro: {type}
      is a type (group, user, assignee, reporter, lead, userCF) of permission granted, or denied to deny the permission.
    • subtasks., if specified, indicates that the permission applies to the subtasks of issues in this step.

    With "wrong" i mean that

    Unknown macro: {permission}

    is really a short name, but they can not be found in Permissions. For example i looked for the ability to grant the permission to create attachments.

    The correct way is to use jira.permission.attach.user - but following your instruction i tried jira.permission.CREATE_ATTACHMENT.user which won't work. So i had to guess the verb attach  

    1. Hello Tobias,

      You can use the getShortName() method to retrieve the correct short name, actually.

      Cheers,
      Yuen-Chi Lian

  4. here it says:

    The format is 'jira.permission.[subtasks.]{permission}.{type}[.suffix]', where:

    But it doesn't say what .suffix is for.

    Update: Ahha, I see in the example the suffix is used, e.g. jira.permission.edit.group.2, so I guess it's simply used when you want to specify a value for the same property more than once and the underlying OSWorkflow system requires unique property keys.

    1. That's the intended usage of the suffix parameter. JIRA is expecting each property to be unique, so if you want to use the same property multiple times you have to tack on a suffix to make it unique.

  5. Hi,

    The WorkflowBasedPermissionManager documentation says:

    group, user, assignee, reporter, lead, userCF

    I took a look at the JIRA 3.11 source code and it is also possible to use projectrole where the value is a JIRA project role ID number. E.g.

    Property Key

    Property Value

    jira.permission.edit.projectrole

    10031

  6. I've started using the step property functionality, but encountered a problem. I'm using sub-tasks, and in one particular step I would like to restrict the create permission, so that only the assignee could create a sub-task in this particular step. I've got the edit, assign and more or less all other permissions to work, but not the create permission. Probably the problem is that I'm using the wrong short name for create.. I've tried jira.permission.create.assignee for example, but I'm sick of guessing (wink) Anyone, helt please! ;S

  7. I can't find a good list of all possible workflow step and transition properties - I see some references to others not listed above and I know having a complete list will help me come up with better workflows.  Can someone please post a definitive list??

  8. See JRA-6381 for examples of restricting workflow steps using the jira.permission.* property.

  9. I have used jira.permission.assignable.projectrole many times with the role-id as its value.

  10. Anonymous

    Watch out for white spaces!

    Leading or trailing white spaces need to be trimmed in workflow transition properties entry boxes. Currently extra spaces cause enties to be unrecognized.

    "jira.field.resolution.exclude " does not equal "jira.field.resolution.exclude"

  11. vr

    I would restrict possibility of Create issue down to a particular project role.

    How can I do this using transition properties on initial Create workflow transition? thanks

  12. Of all those properties, which ones can break bulk operations and which ones dont?

    1. All except sequence, title and submit could potentially stop a bulk operation working. By far the most common case is with editable though.

      1. The ones I'm most interested in are jira.field.resolution.include and jira.field.resolution.exclude . Would that limit bulk operations in a way an issue could be changed to a resolution the workflow does not allow?

        1. I would expect that they do limit bulk operations but I would test it first to confirm that,

          1. I just tried this out (for excluded) and for bulk transitions, it did the right thing (excluded the ones that ought to be).  I tried then to bulk edit, but the resolution field wasn't even in the list of fields I could edit (anyone know if this is on purpose?)  Either way, the setting seems to "do the right thing" for bulk operations. This is JIRA 4.4.4

            1. I think you need to add resolution to the edit screen in order to be able to bulk edit it. Be careful when doing that though, because it'll force someone to pick a resolution every time they edit a ticket, which can lead to people accidentally entering a resolution when they really just wanted to edit the ticket.

  13. I've just found that for jira.field.resolution.exclude (and I suppose the .include one as well), you can't use the .1, .2, .3 suffix to include multiple values.  I had to use a comma-separated list of resolution ID's for the value.

    that is, this didn't work:

    and this did:

    It's not documented above (or elsewhere that I searched) what valid values are. Very frustrating. I suppose it must be a test (If you can't figure it out, you probably shouldn't be using them?)

    1. I hope it'll remain active, I'm using it and it's valuable.

  14. @atlassian Resolutions per workflow step is now broken at the top of this page

    1. Hi Matt. I think someone may have already addressed this, but when I click on that link, it takes me here: Resolutions per workflow step

      1. Still broken for me. The link is https://confluence.atlassian.com/display/JIRA/Workflow+Properties?focusedCommentId=366117619# and it doesn't go anywhere. It's the Reference entry for jira.field.resolution.exclude in the table at the top

        1. Okay, this is really strange. I had a cached version of the page, with the correct link. I cleared my cache, and then saw the behaviour you were seeing. It should be fixed now.

  15. You should also link to Advanced Workflow Configuration#Workingwithtransitionproperties and give a good example with screenshot how to actually set a transition property.

  16. Hello there,
    I'm trying to deny comments for a userCF but I don't find the way to.

    • This is ok to forbid any comment to anyone:
      Property : jira.permission.comment                 Value : denied
    • This is ok to forbid any comment to anyone but my-jira-userCF-name:
      Property : jira.permission.comment.userCF    Value : my-jira-userCF-name

    But I would like to do the inverse... deny permission for my-jira-userCF-name value.
    Could someone help ?

    1. Start with the post at http://www.j-tricks.com/1/post/2011/02/permissions-based-on-workflow-status.html

      Does jira.permission.comment.userCF=denied work? Or jira.permission.comment.customfield_12345=denied, or jira.permission.comment.12345=denied. I bet it's something like that.

  17. Hello Matt,
    First,thanks for your answer. J-triks is great but unfortunately it seems JIRA does not provide any functionality to forbid access to a group nor user nor role... just granting an access is possible.
    Here is my feedback :

    • key : jira.permission.comment.userCF  Value : denied
    • Key : jira.permission.comment.customfield_10704  Value : denied
    • Key : jira.permission.comment.customFieldId=10704  Value : denied
    • Key : jira.permission.comment.userCF.denied  Value : customfield_10704
      All these keys do NOT work. They behaves as if the property was : jira.permission.comment = denied
    • Key : jira.permission.comment.userCF  Value : customfield_10704
      This is not what I want to do but the Key is recognized. It allows the user contained in customfield_10704 to comment the issue (forbidding any other user).
      I just wanna do the inverse ^o^
    1. Time to step back. So you have one user who you never want to be able to comment on an issue. Can you use a permission scheme and the Add Comment permission to do this? A group called users-who-can-comment in there, and don't put your one user in that group. Of course that's for all issues in the a project and all states. 

      One problem is that there are many places in JIRA where users can add comments. I know because I tracked them all down for 4.4 so I could use JavaScript to add a button for surpressing email about the comment. The grungiest way to do this would be to recompile a modified validateCreateComment() method in CommentSystemField.java. Or even hasPermissionToCreate() in DefaultCommentService.java

       

  18. I am a little confused on where I would put the exclude name at in the workflow transition on how the values work. I am working on JIRA 4 with a quick time frame to move to JIRA 6. However there is no JIRA 4 documentation on how you implement this in the workflow transition properties. The fields are property key and property value. Any help or advice is greatly appreciated.

  19. Anonymous

    I'd like to unassign any tickets that reach Closed state.  I have tried jira.issue.assignee and jira.field.assignee but both are not allowed - any way of doing this?

    1. My advice would be to have this done with the workflow Post Functions in the Edit Issue Field have it change the assignee to unassigned as long as you have that selected in the project for tickets to be unassigned.

      1. Anonymous

        Yes, that was my back up plan (I've checked that looks possible), however I have a large number of transformations to Closed (and Resolved, which I would like to do the same with) and hoped to deal with unassigning in one place.

        Thanks for replies though, Bryan and Geoffrey.

    2. Hello,
      Have you tried to add a postfunction that purges the assignee field on Close transition ?
      Edit : Oups I've just saw Bryan's answer...