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

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 and are displayed immediately above the code editor.

Script Context example.

The Script Context for Additional Code and Conditions contain:

  • 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 obscure ScriptRunner Add-on User who may have nothing to do with the issue/project affected.

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

If your scripts are triggered by events invoked by another add-on, they are run as the ScriptRunner Add-on User user even if you set it up to be run as the current user because it’s not possible to impersonate other add-on users. We assume that a user is an add-on user if its name starts with a prefix ' add-on_'.

On this page