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

Compare with Current View Page History

« Previous Version 35 Next »

We highly recommended to test your expression before publishing the workflow.

5 steps to test your expression

Type in your expression or select one of the built-in examples.

Click on the Run button 

Select an issue you want to test your expression with.

Confirm your selection by clicking on Run

Check the resulting output or analyze the errors.

Syntax check

Before running your expression against a certain issue, it's recommended to check if the syntax is correct.

The syntax check button shows if the current expression in the input field is syntactically correct or not . The background check runs every second, but you can also push the Syntax button for instant results.


The run button

By clicking on the Run button, a test expression panel is displayed under your expression. To test your expression, do the following:

  1. Select an issue that you want to test your expression with (as the current issue).
  2. Click on Run



Error messages

Even if the syntax of the expression is correct, it may happen that the expression result is erroneous, e.g. when fields are empty.

In the example below the value of the custom number field "cf10041" is returning a value which is not valid parameter for the function substring().

Output of different data types

Depending on the Parsing modes and the expression itself, different Data types are being returned as a result of the expression.

General mode

Expressions written in the General mode will return texts, numbers or lists.

Logical mode

Expressions written in the Logical mode will return a boolean value of true or false.

Jira expression mode

Expressions written in the Jira expression mode will return objects based on Data types (Jira expressions).

Testing a complex expression

When composing complex expressions, e.g. in Logical mode or the Jira expression mode, where you compare values we recommended to:

Create individual expressions for the operands of the comparison.

Test each expression separately within the selected Parsing modes.

Merge the individual expressions and test the complete expression

Example with screenshots/screencast (I don't know which is the preferred way here) And if someone has a really good exmple instead of mine: please adjust!!

Goal: creating a comment with a remark if an issue is overdue for more than one week

  1. Find issues which fulfill/don't fulfill the condition and use them as the selected "current issue"
  2. Build a condition
    1. General mode: Difference between issue.dueDate and issue.created by using the number values of the dates ({issue.dueDate} - {issue.created} (=> some milliseconds) Remark: display the text values for control with %{issue.dueDate} and %{issue.created} in a separete line 
    2. General mode: Getting the days: extend the expression:  ({issue.dueDate} - {issue.created})/DAY  Remark: omitting the brackets is a nice error source
    3. Logical mode: Adding the comparsion ({issue.dueDate} - {issue.created})/DAY > WEEK
  3. Use this condition as parameter for the conditional operator (General mode): Issue %{issue.key} %{({issue.dueDate} - {issue.created})/DAY > WEEK ? "is overdue" : "is in time"}



Running a test with wrong syntax 

Julian Riedinger brauchen wir das?

Even if you omit the syntax check, you can test your expression using the Run button. In this case, the same error message as for the syntax check is shown.



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