Using Jira Expressions

Cloud Workflows allows you to use "Custom Conditions" and "Custom Validators" in your workflow. These allow you to create conditions/validators that suite your exact needs. Whatever you want for your condition/validator – Cloud Workflows has got you covered. Cloud Workflows does this by using Jira Expression, a powerful DSL build right into Jira. You can read more about Jira Expression in Atlassian's documentation [https://developer.atlassian.com/cloud/jira/platform/jira-expressions/] or in our blog:

Adding a condition/validator with an Jira Expression

When adding a condition/validator to a transition, simply choose '[CW] Custom Condition/Validator' and you're good to go. In the next screen, enter the Jira Expression of your choice save, publish and that's it.

Testing your Jira Expression

Of course, you'll want to make sure that your expression works the way you want it to. Naturally, Cloud Workflows got you covered here, too! Once you got Cloud Workflows installed, you'll notice a new entry in Jira menu: "Jira Expressions". This new page in Jira allows you to test any Jira Expression right there in your browser!

OK, so what's going on here: There are three input fields, a button and a results box. Let's take it from the top.

Every Jira Expression is evaluated in a specific context that determines what kind of data can be used in the expression. (see here for a reference: https://developer.atlassian.com/cloud/jira/platform/jira-expressions-type-reference/)

A user object, referring to the current user, will always be available, other objects (such as project or issue) may or may not be available.

The Jira Expression Test page allows you to pick an issue and a project as additional context information. If you use a Jira Expression in a custom condition/validator, these two will always be available, so you can test your expression under real-life conditions. To add a project or an issue, simply enter the issue's or project's key into the corresponding issue fields.

Examples!

OK, let's see what we can do with this. Here are some examples of what is possible:

The issue must be assigned

This one is pretty easy, we can just check whether the field issue.assignee has been set.

issue.assignee != null

The issue must have an even number of comments

By using the modulo operator we can check whether the list of comments on an issue is even.

issue.comments.length % 2 == 0

The current user must have added a comment to the issue

issue.comments
  .filter(c => c.author.accountId == user.accountId)
  .length > 0

The description must be a least n+1 characters in length

issue.description.length > n

The issue must have more than n comments

issue.comments.length > n

The issue must have more than n subtasks

issue.subtasks.length > n

The issue's parent must not be unassigned

issue.parent.assignee != null

The issue's reporter is a specific person

issue.reporter.displayName == "Peter Petersen"

The issue's reporter is also the assignee

issue.reporter.displayName == issue.assignee.displayName

The issue's priority is 'Medium'

issue.priority.name == "Medium"

The issue type is Story

issue.issueType.name == "Story"

The issue type is either Story or Task

issue.issueType.name.match('^(Story|Task)$') != null


Other cool stuff

If you've read Atlassian's documentation of Jira Expressions, you already know that Jira expressions can do more than just evaluate to true/false. And while it's not really been designed for this, the Jira Expression tester can evaluate any Jira Expression.
So, if you are using Jira Expression elsewhere, for example with the REST API, you can just as easily test the right here.

Let's say you want to get the body of all comments of an issue, this Jira Expression selects just that:

issue.comments
     .map(c => c.body.plainText)

And here's how it looks like when you test it:

Known Limitations

  • Jira Expressions are limited to a maximum of 1.000 characters.
  • Context is limited to user, issue and project when testing expressions.