It is 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.
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.
SCREENCAST Jona Ittermann2
| Output | Description |
|---|---|
| Valid expression: The parser expression entered is valid. |
| Parsing error: The parser expression entered is not valid and you can do the following to fix the issue:
|
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 (insert the green icon) or not(insert the red icon). It's updated every second, but you can also push the button. In the latter case, a pop-up window shows up and displays the result of the syntax check.
Either the syntax is correct:
Or something is wrong with the structure of the expression. A respective error message is shown. In the example below a closing bracket for the function count is missing:
Running a test with wrong syntax
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.
Running a test which returns an error
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 this example the value of the custom number field "cf10041" is returning a value which doesn't suit as a correct parameter for the function substring.
Running tests which return different data types
Please adjust the layout - it's not yet nice or fancy...
Depending on the parsing mode and expression, different types are returned as a result of the expression, e.g.
Boolean values in the Logical mode
Texts, Numbers or Lists when working with the General parsing mode
Objects when using Jira expression mode
The parser expression editor also supports Jira expression mode.
Composing complex expressions
When composing complex expressions like a logical one where you compare values it's recommended to
- create single expressions for the operands of the comparison
- test them with parsing mode General or Jira expressions (depending on the type of parsing mode you need for the condition)
- put them together and test the complete expression with parsing mode Logical and Jira expression, respectively
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
- Find issues which fulfill/don't fulfill the condition and use them as the selected "current issue"
- Build a condition
- 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
- General mode: Getting the days: extend the expression: ({issue.dueDate} - {issue.created})/DAY Remark: omitting the brackets is a nice error source
- Logical mode: Adding the comparsion ({issue.dueDate} - {issue.created})/DAY > WEEK
- 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"}
If you still have questions, feel free to refer to our support team.
