Post Functions Tutorial
Your Jira workflows define the business processes associated with working on different issue types. Workflows can be simple or complex, and they can include several or few workflow functions. Depending on what your organization requires, you may want to use enhanced workflow conditions provided by ScriptRunner. These script conditions allow you to do more in your workflow, providing extra control or information.
All of the ScriptRunner workflows functions are found on the normal Workflows page of Jira Administration (Administration>Issues>Workflows). Edit an existing workflow and click on the transition you wish to add a post function to, then Post Functions>Add Post Function>Script Post Function [ScriptRunner].
For detailed instructions on how to navigate to ScriptRunner workflow functions, see our documentation.
What is a Post Function?
A post function is a workflow function that performs automated actions after an issue transitions to a new status. Every Jira issue has some essential post functions that you can neither remove or edit, but you can add additional post functions to your workflows. And, if you want to take it even further, you can also add scripted post functions. With ScriptRunner, you can add automation for things like creating a sub-tasks, updating issues from sprint placement, and assigning an issue to the first member of a role. In fact, those are all examples of pre-built scripts you can add in your workflow without the need for any custom scripts.
When you select Script Post Function, you see several options on the Select Script page.
There are more pre-built script post functions than script conditions or validators, but you can still create and use your own custom script post functions. One thing you don’t have with script post functions, that you do with script conditions and validators is the option for simple scripted post function.
Script Post Function Options
You have two options for script post functions: pre-built script post functions and custom script post functions.
Pre-Built Script Post Function
ScriptRunner includes several pre-built script post functions. These pre-built options allow you to customize the settings through a series of drop-down menus and fields-no coding required! We don’t cover each of the post functions in detail here, as there are so many. What’s most important to notice is that there are so many ways to add automation without needing to understand groovy or write scripts. This gives you a lot of flexibility in your workflows, even if you aren’t comfortable with code. Here are some of the post functions you can add:
Adds the Current User as a Watcher
Assign to First Member of Role
Create a Sub-Task
Fires an Event When Condition is True
Transition Parent When All Sub-Tasks are Resolved
Set Issue Security Level Depending on Provided Condition
Add/Remove From Sprint
Assign to Last Role Member
Clones an Issue and Links
Fast-Track Transition an Issue
Post a Message to a Chat Service
Send a Custom Email
Adds a Comment to Linked Issues When This Issue is Transitioned
Custom Script Post Function
Custom script post functions require some groovy scripting to use, but allow you to tailor to your needs using inline scripts. You can add the code inline or upload a script file. If you are comfortable working in Groovy, you may want to use this custom option for your scripted post functions in Jira. If you aren’t entirely comfortable, you can still use some script post function recipes available in the Adaptavist Library.
Examples of Script Post Functions
Adds a Comment to Linked Issues When This Issue is Transitioned
This script post function allows you to add a comment on linked issues when the original issue is transitioned. You can select the link type and update the comment. This function is similar to how an automation rule might work in Jira Service Management when specific issues are transitioned, but you can use this script post function in Jira Software or Jira Core. Great Adventure, needs to add comments on blocked issues when the parent blocker issue has been resolved. This comment should indicate that the main issue was fixed and the blocked issue may be closed now.
Add a Script Post Function
For this walkthrough, we are working in Great Adventure’s virtual tour project for an Android app. The linked issues we need to work with are all of the issue type Bugs, so we need to work in the appropriate workflow for that issue type in the project.
Access the project where you want to edit a workflow.
From the project, click Project settings>Workflows from the links on the side, or from the Summary page under Workflows.
On the Workflows page, find the workflow you want to edit, and click the pencil icon under Actions.
On the Edit page, you see a good view of the workflow. In Diagram view, hover over the transition lines to see their names or select Show Transition Labels to display them permanently.
If you want to work in Text view, you can see the transitions listed instead of appearing as lines between statuses.
Click the transition you want to edit to open the Options window.
Under Options, click Post Functions.
Transitions automatically have some post functions, but we are adding a new one, so click Add Post Function.
On the Add Post Function to Transition page, select Script Post Function and then Add.
Make your selection. For this example we chose Adds a Comment to Linked Issues When This Issue is Transitioned. If you have a question about any of the choices, you can click the Help icon.
For many of the built-in post functions that have code boxes, you can choose to see examples, and if one of the examples works for your needs, just click it to add the scripted version to your code box automatically.
Complete the fields as needed.
In the Issue Link Type field, choose the issue link type of Blocks.
In the Comment field, type the comment to apply to the blocked issues on transition. For this example, we use the provided example:groovy
Blocking issue $issue resolved with resolution < % out << issue.resolution?.name % >.
When copying the code above remove the space between < and %.
Click Preview to see a summary of what the post function does.
Click Add when you are happy with it and you then see your new post function on the resulting screen.
When working with post functions, any items you add must be underneath the pre-generated post functions. You reorder post functions via the arrow icons on the right of the function (they can only move one line at a time). So move your new post function to its proper place.
Testing a Script Post Function
At the top of the workflow edit screen, click Publish. A message appears about saving a backup of the current workflow.
For this demo you may not need to, but we recommend you save backups in your daily work.
Select Publish to publish the workflow.
Now, you want to run some issues through to test this new process. Log in as a test user with access to the project that has your updated workflow.
Create an issue and a blocked issue that uses the workflow you edited. Transition the issue to where you added the scripted validator.
Move the issue that "blocks" (found under Issue Links) through the workflow until it is closed.
When finished go to the blocked issue.
Under Activity, you should see the comment added automatically via the script post function. If you see the comment added, you are good to go with this script post function!
This scripted post function closes all sub-tasks of an issue when the parent issues closes with a Resolution of Fixed. In some cases, you may want to close sub-tasks automatically when you close a parent task, and this script post function can handle that situation. You place this post function on the Resolve transition of the workflow. Just copy/paste the following into the Custom Script Post Function option on the Select Script page.
This post function is successful if, when the primary task is marked as Done with a Resolution of Fixed, all associated sub-tasks are also closed. If you wanted to specify another type or resolution for this auto-close of sub-tasks, you would need to update the script.
As always, we recommend that you do any script testing in a test instance and not your production instance.