Scripted (Groovy) Validator

A workflow validator that is based on the result of a Groovy expression. If the Groovy expression returns false, a validation error message will be displayed.

To add 'Scripted (Groovy) Validator' to a transition:

1. Click Edit for the workflow that has the transition you wish to configure the validator on.

2. In the Workflow Designer, select the transition.

3. Click on Validators in the properties panel.

4. Click on Add validator.

5. Select Scripted (Groovy) Validator from the list of validators.

6. Click on Add to add the validator.

7. Write a Groovy expression in the Groovy script field.

8. Input a message in the Error message field.

9. Select on which field the error message should be displayed.

10. Click on Add to add the validator to the transition.

On the Service Management portal view of a request, the customer will not see the Error message when the validator fails. This is due to a known limitation (JSDSERVER-5822) with Atlassian. However, you can still customize the Error message using this workaround.

Related links:

• Use cases for validators

• Writing Groovy scripts

Open

When you add this validator to a transition and trigger the transition, the add-on checks the result of the groovy expression. If it returns false or a Groovy falsy, a validation error message is displayed.

Expected value

Click on the "Expected Value" tab in the Groovy editor help for a few examples on the expected value for the validator.

The value should be either:

• A boolean value (true if validation passes or false if validation fails). For example, Fail the validation if the current user is not the reporter of the issue

  issue.reporter.name == currentUser.name

• A String representing the error message to display (meaning that the validation fails). For example, Prevent the user from moving forward if the issue is unassigned

  if(!issue.get("assignee")){ "You cannot move forward since the issue is unassigned" }

  If the issue is unassigned, then the message "You cannot move forward since the issue is unassigned" will be displayed. Note that you cannot include HTML in the error message because Jira escapes HTML in the error message.

• A Map<String,String> where each key is a field name or ID and the corresponding value is the error message to display for that field. For example, if the script returns:

  ["summary":"Too long","Description":"Too short"]

   then Too long will be displayed below the Summary field, and Too short will be displayed below the Description field. Note that the field can be identified either by its name or its ID.

• or else, any value that will be interpreted as either "truthy" (validation passes) or "falsy" (validation fails)

  this returns the Resolution object which is considered truthy.

Examples of custom validators

With simple Groovy scripting, you can create custom validators that fit your purpose using this Validator. 

For example, if you want to prevent the user from resolving an issue if the issue has an unreleased Fix Version/s either from before or added during the transition:

In this validator, you can access the values modified during the transition using the getModifiedFields() method of the Issue interface. For example, if you want to check during a transition that the issue is assigned to a specific user:

In this validator, you can access the issue fields before and during/after the transition using the originalIssue and issue variables respectively. For example, during a Story modification, you want to check that the Story points of the Story have not been raised by more than 5:

Look here for more use cases for this validator.