Custom Post Functions

For a tutorial on workflow post functions, see the Post Functions Tutorial page.

Most of the built-in workflow functions can be customized with Condition code or Additional actions code, so if you can use a built-in script, you should.

Post functions

Post functions execute after the transition has been validated. Here is the place where you can pass on a message to a downstream system, send custom notifications or modify the issue etc.

Post function order

The order of the post functions is important. For example, a post function that changes the description of the issue - issue.setDescription("A new description") - should be placed before the Update change history for an issue and store the issue in the database step. Fast track transition an issue should be placed after the Fire Event step.

Where to put your scripts?

You can write your script inline, or if you prefer to use files, you can use the File tab and provide the absolute path or a relative path to a script stored in one of your script roots. Relative paths are more portable and make switching servers easier.

Script binding

For each type of workflow function, the plugin provides several binding variables. For example, there is a log variable to help debug your scripts, an issue variable to access the current issue that the function applies to, and a transientVars map variable to access variables unique to the transition. 

To view the script binding variables, click the small blue circle with a ? near the script input area. 

 
def issueKey = issue.key

def actionId = transientVars['actionId']

log.debug("Issue key is ${issueKey}, and the action id is ${actionId}")

Examples

Append generated comment

Automatically append some generated comment on a transition.

In this case we add a comment if a user resolved an issue which had unresolved subtasks:

if (issue.subTaskObjects.any { !it.resolution }) {
    issue.addComment('I resolved this issue even though there were unresolved sub-tasks...') {
        setDispatchEvent(false)
    }
}

Auto add reviewers based on request type

Case Study:

When an issue is created, users have to manually select the reviewer of their task. The admin wants to set it automatically depending on the request.

This makes sense if, for example, a purchase over 100 dollars needs to be cleared by one department and a travel request needs to be cleared by your manager.

Steps:
  1. Select the onCreate transition of your workflow.
    Remember this can only be accessed through the diagram, and not the text editor.

  2. Select Add post function > Custom script post-function.

    It is very important that this is the FIRST function if set on the onCreate transition, else it will not update your value.

  3. Add the following code:

    Please note that in this case study, we want to add reviewers for the two basic request types that require reviewers: "Purchase Over $100", and "Travel Request".

    Include Bitbucket for Confluence: File content cannot be shown

    Unauthenticated access to this resource is not allowed. Please login to Confluence first.

Auto close sub-tasks

Script to Resolve all currently Open sub-tasks.

def subTasks = issue.subTaskObjects
subTasks.each { subTask ->
    if (subTask.status.name == "Open") {
        subTask.transition('Resolve Issue') {
            setResolution('Done')
        }
    }
}

Get workflow steps

Get the current action name

In a workflow function, to get the ID of the action (which is normally what you want rather than the name), use:

 
transientVars["actionId"]

To get the action name you can use:

import com.atlassian.jira.component.ComponentAccessor

def workflow = ComponentAccessor.getWorkflowManager().getWorkflow(issue)
def wfd = workflow.getDescriptor()
def actionName = wfd.getAction(transientVars["actionId"] as int).getName()
log.debug("Current action name: $actionName")

Get the previous and destination steps

Getting the current and destination steps depends on whether your function is placed above or below the functions to update the issue in the database and reindex.

The following code:

 
issue.status.name

will return the current status - so if your script function is before the built-in functions to update the issue it will return the "previous" status, if it is after it will return the destination status.

To get the destination step use:

import com.atlassian.jira.component.ComponentAccessor
import com.opensymphony.workflow.spi.Step

def step = transientVars["createdStep"] as Step
def stepId = step.getStepId()
def status = ComponentAccessor.getConstantsManager().getStatus(stepId as String)

log.debug(status.name)

Set issue fields

You can see some issue fields as part of a post-function, for instance components, versions, custom and system fields.

The following example covers these areas.

You can only use this method to update issue fields if your script post-function comes before the standard function Update change history for an issue and store the issue in the database. If you need your function to run after that, you have to use a more complex method.

import java.time.LocalDate

issue.set {
    setFixVersions('1.1')
    setComponents('MyComponent')

    // a text field
    setCustomFieldValue('TextFieldA', "Some text value")

    // a date time field - add 7 days to current datetime
    setCustomFieldValue('Date Picker') {
        set(get().plusDays(7))
    }

    // checkboxes, radio buttons, single and multi selects
    setCustomFieldValue('Checkboxes', 'Yes')

    // a user custom field
    setCustomFieldValue('UserPicker', 'admin')

    // system fields
    setDescription("A generated description")

    // set due date to tomorrow
    setDueDate {
        set(LocalDate.now().plusDays(1))
    }
}


On this page