You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 40 Next »

The Jira expression parsing mode, unlike the General mode and the Logical mode, is based on a domain-specific language designed and provided by Atlassian, not JWT.

It can be used to evaluate custom Jira expressions. Jira expressions follow JavaScript syntax and can be thought as a JavaScript dialect. See the introduction section from the official documentation here

(warning)JWT for Jira Cloud only uses the features provided by Atlassian which cannot be modified by JWT for Jira Cloud!



Where are Jira expressions used in JWT for Jira Cloud?

Jira expressions can be used whenever the Jira expression mode is available. Currently this parsing mode is the only available parsing mode in the:

Additionally the Jira expression mode is available when configuring the conditional execution parameter in workflow Post functions.


In order to illustrate with a simple example, the following Jira expression would ensure that an issue is currently assigned to a Jira user.

issue.assignee != null

What is the difference to JWT expressions?

While they might look quite same, it is important to know that Jira expressions and the JWT expressions have nothing in common in the background.

The equivalent to our former example, using JWT expression field codes would read:

%{issue.assignee} != null

Apparently, one of the main differences to Jira expressions is the way the field codes are referenced.

Rule of thumb!

If you spot %{...} the syntax is being used in a JWT expression (either the General mode or the Logical mode). If the % sign is missing you are likely looking at Jira expressions written in the Jira expression mode.

 Example expressions

Parser expressionDescription
issue.reporter.displayName == "John Doe"

This example makes sure that the current reporter is "John Doe".

issue.issueType.name == "Story"

This example makes sure that the current issue type is a "Story".

Additional examples
Compare field values
Jira expressionDescription
issue.priority.name == "Medium"
Issue's priority must be "Medium".
issue.issueType.name.match('^(Bug|Task)$') != null

Issue type must be "Bug" or "Task" (using a regular expression).

issue.assignee.displayName == issue.reporter.displayName
Issue's assignee must be the reporter.
Numbers and dates

Counting elements

You can count elements by adding .length

Jira expressionDescription
issue.description.plainText.length >= 100
Issue's description must be at least 100 characters in length.
issue.comments.length >= 5
Issue must have at least 5 comments.
issue.subtasks.length == 2
Issue must have exactly 2 sub-tasks.
new Date().getDay() != 1

The current day must not be Monday.

(warning)  (see JavaScript reference for getDay())

Work with lists
Jira expressionDescription
issue.subtasks.every(s => s.status.name == 'Done')

Issue's sub-tasks must all be in the status of DONE

issue.comments.some(com => com.body.plainText.match('([A-Z][A-Z0-9]+)-\d+') != null)

Issue must have at least one comment containing an issue key (using a regular expression).

issue.subtasks.some(sub => sub.components.some(comp => (comp.name == "QA")))

Issue must have at least one sub-task with the component "QA" set.

issue.subtasks
.every(sub => sub.comments
.some(com => com.body.plainText.match('([A-Z][A-Z0-9]+)-\d+') != null))
Every sub-task of the issue must have at least one comment containing an issue key (using a regular expression).
issue.comments
.map(c => c.body.plainText)
.filter(text => text.length > 99)
.length > 0
Issue must have at least one comment with at least 100 characters in length (n+1).
issue.links
.filter(link => link.type.name == "Blocks"  )
.length == 0
The issue must not have a link of type Blocks.
issue.links
.filter(link => link.linkedIssue.status.name == "Done")
.length == issue.links.length

All linked issues must be in the status DONE

issue.links
.filter(link => link.linkedIssue.issueType.name == "Bug" && link.linkedIssue.resolution != null)
.length == issue.links
.filter(link => link.linkedIssue.issueType.name == "Bug")
.length

All linked bugs must be resolved.


Why do I need both?

Right now, Jira expressions are the only officially supported way to formulate custom conditions or validators in Jira Cloud.

Being the "brain" of Jira Workflow Toolbox for Server and Data Center, its JWT expression editor and the underlying expression parser, have evolved from a small set of handy functions to a comprehensive list and a fundamental part of this app over the years.

Therefore it was only obvious to make this core functionality available for Jira Cloud as well.



Where do I start?

Familiarize yourself with the Jira expression mode. Once you have a general overview make sure to check out the various use cases  we have prepared for you.

To deep-dive into Jira expressions we suggest reading up on the additional information we have prepared for you:



What else should I know?

Jira expressions follow certain constraints with regard to the evaluation of those expressions (see the official documentation).

While the limits should be high enough not to interfere with any intended usage, it's important to realize that they do exist:

  • Expression length is limited to 1,000 characters or 100 syntactic elements.
  • Expressions don't support logging or custom error messages. Any non-boolean value will be considered as false 
  • Expressions can execute a maximum of 10 so-called "expensive" operations, i.e. those that load additional data, such as entity properties, comments, or custom fields, e.g.
    Given an expression to check whether every sub-task has at least one comment containing an issue key, will fail if this issue has more than 10 sub-tasks.


issue.subtasks.every(sub => sub.comments.some(com => com.body.plainText.match('([A-Z][A-Z0-9]+)-\d+') != null))



Need additional resources?

The best way would be to start with the official documentation:


If you still have questions, feel free to refer to our support team.