Built-in Post Functions
You can use the many ScriptRunner for JIRA Cloud built-in post functions, outlined below.
Add/Remove to/from Sprint
Using this post function, you can either add an issue to an active sprint or remove it from its current sprint after a transition.
For example, on the Start Progress transition, you can apply this post function to add the transitioned issue to the current sprint automatically. Although this does not follow scrum methodology, there may be times the team has finished all work in a sprint, and this post function allows issues to be added to the sprint automatically.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Add/Remove from Sprint built-in post function.
Add a description of the post function in Description for example, Add Issue to Sprint.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is added/removed to/from sprint. See Conditions for examples.
Select the Action you want to trigger after transition (either Add to Sprint or Remove from Sprint).
Choose the Board Name. The function picks the first active sprint from that board.
Pick the user to run the script as in Run As. See Run as User for more information.
Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Assign Issue
Assign Issue takes the issue and assigns it to the last assignee with a specified role or from a user group. You must specify either project role or a user group. If both are defined, the project role is used, and the user group is skipped.
For example, a developer finishes working on an issue and marks it as Ready to Test. After the issue is transitioned, the issue is automatically assigned to a tester. The tester rejects the issue, and it returns to the development team. The last user assigned in the development role is re-assigned to the issue. The dev can then fix the issue, and transition it back to the QA team. When they do, the issue is re-assigned to the same tester (last user in the tester role).
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Assign Issue built-in post function.
Add a description of the post function in Description for example, Assign to last developer.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is assigned. See Conditions for examples.
Either select a Project Role (for example, Developer) or User Group. The last user with this role/in this user group is selected after the issue has transitioned.
Pick the user to run the script as in Run As. See Run as User for more information.
Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Clone Issue
Clone Issue creates a clone of a selected issue and optionally links the two issues. Specify the target project, issue type, link type, and link direction (between the source issue and the clone). For example, you have a ticket for a potential new hire. When this ticket transitions to Hired you want to automatically clone the issue to the IT board so the team can set up their login details.
An epic post function can be cloned, however, the issues contained within that epic are not cloned. You will, therefore, need to recreate any associated issues.
It is possible to override issueInput
with a new structure by setting issueInput
from additional code; however, this is not recommended.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Clone Issue built-in post function.
Add a description of the post function in Description for example, Create IT ticket.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is cloned. See Conditions for examples.
Select an Issue Type for the cloned issue. Leave this field blank to make the cloned issue the same type as the source issue.
Select a Target Project; this is the project the new cloned issue is assigned to. Leave this field blank to clone the issue to the same project as source issue.
Pick the user to run the script as in Run As. See Run as User for more information.
Select a link type under Link Name. The source issue and the clone are linked using this link type. Leave blank for no link.
Select the Link Direction between the source issue and the clone.
In the Additional Code field modify the
issueInput
structure before it is used as the POST body to/rest/api/2/issue
to create the issue. For example, add a label, set an assignee, or update the summary of the clone.Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Supported Field Types
The Clone Issue function only copies Jira system fields and any custom fields which have the following types:
Checkbox
Date picker
Date time picker
Labels
Number field
Radio button
Select list
Multi-select list
Single text field
Multi-row text field
URL field
User picker
Group picker
Multi-select group picker
Project picker
Multi-select user picker
Version picker
Multi-select version picker
Fields created by other plugins might not be supported. However, it is possible to add additional code to the configuration to include them.
Create Sub-task
Create a sub-task for the issue being transitioned. Specify the sub-task type and title along with executing additional code. Additional code has issueInput
bound as the structure that is used in the post to /rest/api/2/issue
to create the sub-task. Overriding issueInput
is possible by setting issueInput
as part of the script.
For example, a ticket needs to be checked by several departments before it is considered Done. Using this post function, you can automatically create sub-tasks for these departments when a ticket is created.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Create Sub-task built-in post function.
Add a description of the post function in Description for example, Department sub-tasks.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the sub-task is created. See Conditions for examples.
Enter a short Sub-task Summary.
Select the sub-task Issue Type
Pick the user to run the script as in Run As. See Run as User for more information.
In the Additional Code field, modify the sub-task structure before it is used as the POST body to /rest/api/2/issue to create the sub-task.
Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Create Sub-Task Example
Here is the code we run under the hood in the provided function, modified so you can run it in the script console:
groovy// Here we specify and retrieve the details of the parent issue // If you copied this code into a Post Function or an issue-related Script Listener you could remove // the first 5 lines of code as an issue variable would already be available to your script def parentKey = 'DEMO-1' def issueResp = get("/rest/api/2/issue/${parentKey}") .asObject(Map) assert issueResp.status == 200 def issue = issueResp.body as Map // We retrieve all issue types def typeResp = get('/rest/api/2/issuetype') .asObject(List) assert typeResp.status == 200 def issueTypes = typeResp.body as List<Map> // Here we set the basic subtask issue details def summary = "Subtask summary" def issueType = "Sub-task" def issueTypeId = issueTypes.find { it.subtask && it.name == issueType }?.id assert issueTypeId : "No subtasks issue type found called '${issueType}'" def createDoc = [ fields: [ project: (issue.fields as Map).project, issuetype: [ id: issueTypeId ], parent: [ id: issue.id ], summary: summary ] ] // Now we create the subtask def resp = post("/rest/api/2/issue") .header("Content-Type", "application/json") .body(createDoc) .asObject(Map) def subtask = resp.body assert resp.status >= 200 && resp.status < 300 && subtask && subtask.key != null subtask
Fast-Track Transition Issue
Use Fast-track Transition Issue to immediately transition an issue if the provided condition is true. Transitions are specified by name and must be valid for the issue that is to be transitioned.
Due to limitations in the Jira REST API, it is not possible to validate transition names until execution.
For example, all issues that have the issue priority Major should be escalated to get additional sign-off after creation.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Fast-track Transition Issue built-in post function.
Add a description of the post function in Description for example, Requires Additional Approval.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is transitioned. See Conditions for examples.
Enter a comment to add during the transition in Transition Comment.
A comment is only added if the transition allows adding a comment.
Enter a Transition ID. This is the ID of the transition you wish to perform on the issue.
The transition ID is found on the Edit page of a workflow. It is the number in brackets after the transition name. For example, the ID for the transition OPEN (1) is 1.
Alternatively to using the Transition ID, you can specify a Transition Name. TIP: It is recommended that a transition ID is used instead of the transition name because, in some cases, it is not possible to find transition ID by name (for example, if the Hide From User Condition is configured on the transition).
Pick the user to run the script as in Run As. See Run as User for more information.
In the Additional Code field, modify the
transition
structure before it is used as the PUT body to/rest/api/2/issue/<issue.id>/transition
to modify the issue when transitioned.- Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Modify Issue
Update the issue, or perform any action on the issue after a transition. TIP: Cancel an update by setting issueInput
to null
. Cancelling an update allows you to use this post function in a similar way to a script listener.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Modify Issue built-in post function.
Add a description of the post function in Description for example, Change assignee when approved.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is modified. See Conditions for examples.
Pick the user to run the script as in Run As. See Run as User for more information.
Modify the
issueInput
structure in Additional Code before it is used as the POST body to/rest/api/2/issue/<issue id>/notify
to modify the issue.Running as the add-on user adds
overrideScreenSecurity=true
as a query parameter to allow editing fields that are not on the screen.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Run Script
Run arbitrary code after a transition.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Run Script built-in post function.
Add a description of the post function in Description.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the script is run. See Conditions for examples.
Pick the user to run the script as in Run As. See Run as User for more information.
In the Code field, add the code to run when the condition is true. For example, link an issue, update an issue or add a comment.
Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
Send Notification
Generate an email notification to send to a number of users and/or groups including Watchers, Voters, the Reporter, and Assignee.
The notify API, which this script uses, contains a validation rule preventing users from notifying themselves. This means that the execution fails if the user being notified is the same user who executed the script.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Send Notification built-in post function.
Add a description of the post function in Description for example, Notify when work starts.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the notification is sent. See Conditions for examples.
Specify who receives the notification:
Select the users to notify. Check to notify watchers, voters, the reporter, or assignee.
Choose users to send the notification to in the Users field.
Enter the Groups to send the notification to.
Specify a minimum of one recipient.
Enter the notification Subject.
Enter the notification body ad Groovy code in Message.
Use the Email Template example as a starting point.
Pick the user to run the script as in Run As. See Run as User for more information.
Modify the
notification
structure in Additional Code before it is used as the POST body to/rest/api/2/issue/<issue id>/notify
to send the notification.Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.
The following is an example of constructing an email from the issue details.
Use the following in the Condition field to specify that the issue must have an assignee:
issue.fields.assignee != null
Enter the following into the Message field to retrieve the value for the 'TextFieldB' custom field and construct the notification body:
groovydef fields = get('/rest/api/2/field') .asObject(List) .body as List<Map> defcustomFieldId = fields.find { it.name == 'TextFieldB' }.id as String defcustomFieldValue = (issue.fields[customFieldId] as Map)?.value """Dear ${issue.fields.assignee?.displayName}, The $(issue.fields.issuetype.name} ${issue.key} with priority ${issue.fields.priority?.name} has been assigned to you. Description: ${issue.fields.description} Custom field value: ${customFieldValue} Regards, ${issue.fields.reporter?.displayName}"""
Line 5: Retrieve the custom field ID for the 'TextFieldB' custom field.
Transition Parent Issue
Transition the parent issue of a sub-task.
This post function is only valid for sub-tasks and will not work on parent issues, or issues with no sub-tasks.
The specified transition is performed on the parent of the sub-task when a condition is met. As with Fast-Track Transition Issue, the transition name is provided and not validated.
Select a transition.
Click Post Functions→Add Post Function.
Select ScriptRunner Post Function and click Add.
Select the Transition Parent Issue built-in post function.
Add a description of the post function in Description for example, Transition parent when done.
Check Enable Post Function to make this post function active as soon as creation is finished.
Add additional Groovy code in the Conditions field that returns a boolean value determining the condition for which the issue is transitioned. See Conditions for examples.
Enter a comment to add during the transition in Transition Comment.
A comment is only added if the transition allows adding a comment.
Enter a Transition ID. This is the ID of the transition you wish to perform on the parent issue.
The transition ID is found on the Edit page of a workflow. It is the number in brackets after the transition name. For example, the ID for the transition OPEN (1) is 1.
Alternatively to using the Transition ID, you can specify a Transition Name. TIP: It is recommended that a transition ID is used instead of the transition name because, in some cases, it is not possible to find transition ID by name (for example, if the Hide From User Condition is configured on the transition).
Pick the user to run the script as in Run As. See Run as User for more information.
In the Additional Code field, modify the
transition
structure before it is used as the PUT body to/rest/api/2/issue/<issue.id>/transition
to modify the issue when transitioned.Click Add.
See the available Script Context for Condition and Additional Code fields in the Script Context section.