Fields

Post function condition

A post function Condition 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

The area immediately above the code editor displays the Script Context parameters already available in your code and a link to more documentation.

Additional code

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

The area immediately above the code editor displays the Script Context parameters already available in your code and a link to more documentation.

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 post function. 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 issue as a map, for more details, see Atlassian Connect Workflow Post Function Documentation.

Run as user

Post Functions 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 post function (Initiating User).

When using the Initiating User, any action occurring as a result of the function is registered as being performed by them. For example, if an issue 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 issue or project 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 project 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 project.