Fields

Perform Actions rule

A Perform Actions rule field provides additional logic to restrict execution beyond what is achievable using workflow schemes. For example, issue.fields.summary ==~ /^(?i)foo./ ensures the function only executes if the *Summary starts with "foo" (case insensitive).

Other examples include:

• Never Execute: false

• Match only a specific issue type: ((Map) issue.fields.issuetype)?.name == 'Task'

• Ensure that fields are present; in this case, assignee must be set: issue.fields.assignee != null

As shown in the image below, the area immediately above the code editor provides access to Example scripts and displays the Script context parameters already available in your code. You can also Load and/or edit saved scripts from Script Manager when using the perform actions rule.

Additional code

The Additional Code field allows users to enter a script to run an additional action after a work item is transitioned. For example, you may want to add a comment when a parent work item is transitioned as part of a Perform actions rule: addComment.body = "$ {issue.key} caused this to be transitioned".

The Additional Code code editor provides you with the same options as the perform actions Condition mentioned above.

Script context

The Script Context provides a set of parameters/code variables that are automatically injected into your script to provide contextual data for the Perform actions rule. They are also available for the Condition and Additional Code fields.
To view, click Script context and a pop-up modal displays, as shown below:

The Script Context for Additional Code and Conditions contains:

• baseUrl - Base URL to make API requests against. This is the URL used for relative request paths. For example, if you make a request to /rest/api/2/issue we use the baseUrl to create a full request path.

• logger - Logger to use for debugging purposes.

• issue - Transitioned issue details available as a map. For more details, see Get Issue REST API Reference.

• transitionInput - The transition for the work item as a map. For more details, see Atlassian Connect Workflow Post Function Documentation.

Run as user

Perform actions rules can make requests back to Jira using either the add-on user (ScriptRunner Add-On User) or the user that performed the transition that triggered the perform actions rule (Initiating User).

When using the Initiating User, any action resulting from the rule is registered as performed by them. For example, if a work item is commented on, the comment comes from the Initiating User rather than the ScriptRunner Add-on User, who may have no direct connection to the work item or space affected.

Permissions are always considered when executing actions. The user selected in the Run as User field must have the correct permissions to perform the specified action. Typically, the ScriptRunner Add-on User has space admin permissions; however, these can be restricted. The Initiating User may have higher permissions than the ScriptRunner Add-on User, depending on their role in the space.