Jira Expression of the Week — Separation of Concerns

Our clients quite often have very specific requirements around their processes, with a lot of restrictions to apply. For this week’s Jira Expression, we will look into how one rather common of these restrictions can be implemented: A separation of concerns. The restriction is: An issue may not be transitioned to the next state if it is owned by the same owner as its parent. For example, a Product Owner who owns a Story should not be able to put the corresponding Tasks to In Progress.

To enforce this restriction in a workflow, we will use a custom workflow condition with a Jira Expression that returns either true or false, just like the one from last week did.

To use a custom condition like the one described in this article, you will need a Jira Cloud app that supports conditions. We suggest Cloud Workflows which brings new conditions and validators to Jira Cloud! Thanks to either our easy templates or your custom Jira Expressions, you gain more fine-grained control of your workflows. Our flexible post-functions further enhance your workflow’s productivity. It’s available from the Atlassian Marketplace!

To build our expression, we need to know just a couple of things:

• The user who or attempts to perform the transition
• The assignee of the parent issue

We will use the accountId to identify a user in Jira, even though other options are available. The accountId is guaranteed to be unique and available throughout Atlassian’s API and does not have the privacy concerns that apply to other attributes such as the user’s e-mail address. See here for more information.

By this point, you should already be familiar with the information available in the current issue, but can go ahead and check out part 1 and part 2 of this series.

We will use the user-object to get the current user’s accountId. As you might have guessed, the user-object holds information about the user performing the transition (whereas current assignee’s name does not help us that much since it is possible that someone else is trying to perform the transition).

user.accountId

Accessing the current user’s accountId

Of course, the output here is some random-looking id, but it is guaranteed to be a unique identifier of the current user. We are halfway there, yippie!

Next up, we need the assignee of the parent issue. Unfortunately, there is no parentIssue-object directly available in the context. Or is there? A quick look at Atlassian’s reference documentation tells us that issues have an attribute called parent. Which — you guessed it — is just another issue-object, only that it represents the parent of the issue:

issue.parent.assignee.accountId

Accessing the parent issue’s assignee

Almost done, the only thing left is to compare both assignees. Jira Expressions give us a range of options, but for now we only need one: != which translates to does not equal. (The opposite would be ==, which we would have used if we required both issues to have the same assignee.)

So, to compare both issues’ assignees we can now write the following expression and add it as a workflow condition:

user.accountId != issue.parent.assignee.accountId

Adding a Jira Expression as a Workflow Condition

And there you have it, simple as that. if you want to use this or any other kind of Jira Expression in your workflows, check out Cloud Workflows!

Next week we will look at how to build much more complex Jira Expressions.