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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Add/Remove from Sprint built-in post function.

  5. Add a description of the post function in Description for example, Add Issue to Sprint.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Select the Action you want to trigger after transition (either Add to Sprint or Remove from Sprint).

  9. Choose the Board Name. The function picks the first active sprint from that board.

  10. Pick the user to run the script as in Run As. See Run as User for more information.

  11. 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).

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Assign Issue built-in post function.

  5. Add a description of the post function in Description for example, Assign to last developer.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. 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.

  9. Pick the user to run the script as in Run As. See Run as User for more information.

  10. 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.

It is possible to override issueInput with a new structure by setting issueInput from additional code; however, this is not recommended.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Clone Issue built-in post function.

  5. Add a description of the post function in Description for example, Create IT ticket.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Select an Issue Type for the cloned issue. Leave this field blank to make the cloned issue the same type as the source issue.

  9. 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.

  10. Pick the user to run the script as in Run As. See Run as User for more information.

  11. Select a link type under Link Name. The source issue and the clone are linked using this link type. Leave blank for no link.

  12. Select the Link Direction between the source issue and the clone.

  13. 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.

  14. 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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Create Sub-task built-in post function.

  5. Add a description of the post function in Description for example, Department sub-tasks.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Enter a short Sub-task Summary.

  9. Select the sub-task Issue Type

  10. Pick the user to run the script as in Run As. See Run as User for more information.

  11. 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.

  12. 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:

// 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
GROOVY

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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Fast-track Transition Issue built-in post function.

  5. Add a description of the post function in Description for example, Requires Additional Approval.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Enter a comment to add during the transition in Transition Comment.

    A comment is only added if the transition allows adding a comment.

  9. 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.

  10. 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).

  11. Pick the user to run the script as in Run As. See Run as User for more information.

  12. 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.

  13. 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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Modify Issue built-in post function.

  5. Add a description of the post function in Description for example, Change assignee when approved.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Pick the user to run the script as in Run As. See Run as User for more information.

  9. 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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Run Script built-in post function.

  5. Add a description of the post function in Description.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Pick the user to run the script as in Run As. See Run as User for more information.

  9. 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.

  10. 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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Send Notification built-in post function.

  5. Add a description of the post function in Description for example, Notify when work starts.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Specify who receives the notification:

    1. Select the users to notify. Check to notify watchers, voters, the reporter, or assignee.

    2. Choose users to send the notification to in the Users field.

    3. Enter the Groups to send the notification to.

      Specify a minimum of one recipient.

  9. Enter the notification Subject.

  10. Enter the notification body ad Groovy code in Message.

    Use the Email Template example as a starting point.

  11. Pick the user to run the script as in Run As. See Run as User for more information.

  12. 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.

  13. 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:

def 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}"""
GROOVY


  1. 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.

  1. Select a transition.

  2. Click Post Functions→Add Post Function.

  3. Select ScriptRunner Post Function and click Add.

  4. Select the Transition Parent Issue built-in post function.

  5. Add a description of the post function in Description for example, Transition parent when done.

  6. Check Enable Post Function to make this post function active as soon as creation is finished.

  7. 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.

  8. Enter a comment to add during the transition in Transition Comment.

    A comment is only added if the transition allows adding a comment.

  9. 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.

  10. 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).

  11. Pick the user to run the script as in Run As. See Run as User for more information.

  12. 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.

  13. Click Add.

See the available Script Context for Condition and Additional Code fields in the Script Context section.