Writing Post-Functions (Actions)
Post-functions are the actions on the workflow and are executed in the final stage of the transition. They have no special requirements on returns, and always execute in the context of the transitioned issue.
A post-function may be as simple as:
assignee = currentUser();
Or, add complexity to meet a specific requirement.
Unlike validators and conditions, the post-function is the only place in the workflow where you can modify the issue.
Parameters
On the Cloud, the only derived parameter is the post-function ID. It is passed as the only parameter in the execution of the script, allowing you to create decisions.
An example is below:
And the corresponding script:
logPrint("ERROR", "Postfunction execution - Current user is :" + currentUser() + " postfunction id:" + argv[0]);
switch(argv[0]) {
case "e6132922-74c4-4315-84f0-32bcb70cddf4": //this is the first postfunction
logPrint("ERROR", "This is the end, my only friend " + currentUser());
break;
case "9c5bbeda-f20c-44ae-bda4-272203e3b412": //this is the second postfunction
logPrint("ERROR", "The end of our elaborate plans, the end of everything that stands");
break;
}
The output is (on the ERROR level, where the message was pushed):
Postfunction execution - Current user is :6093b81a539c14006ad3c137 postfunction id:e6132922-74c4-4315-84f0-32bcb70cddf4 This is the end, my only friend 6093b81a539c14006ad3c137 Postfunction execution - Current user is :6093b81a539c14006ad3c137 postfunction id:9c5bbeda-f20c-44ae-bda4-272203e3b412 The end of our elaborate plans, the end of everything that stands
Even if the script is the same, the different integration points generate unique IDs (on different transitions and workflows). Therefore, you may use this strategy to apply small changes to the logic depending on your location. However, these IDs are not portable from install to install.
The goal is for this information to assist you in script reusability.
Runtime User & Issue
Post-functions execute with the user activating the transition, no matter if it’s declared as asynchronous or synchronous. If the transition is triggered by another automation or addon that does not act as the triggering user, the current user may be null, in which case you will need to deal with it programmatically.
Scripts are executed within the issue context.
Return Codes For Post-Functions
return;
Note that “return;” ends the program and any values returned by the script are ignored.
Order of the Post-functions
In general, it’s recommended to place post-functions after all standard post-functions. This allows the issue to be re-indexed and the data stored correctly.
The new issue has not been indexed if the post-function is applied to the “create” transition. Also, the index does not exist until the index step runs for the first time, and no data may exist for the issue. For these reasons, it is always best for the post-function to be after all the standard post-functions.
Note
When writing post functions, ensure the SIL program is the last step of the transition. This is required because Jira needs to create or update the issue and save it to the database before SIL can access it. Unlike the DC/Server product, the Cloud version is limited in altering the UI and providing hints.
As an example, we will reuse the above configuration example:
However, this time, let’s modify the post-function script to read:
logPrint("ERROR", "The status is :" + status); // such a simple script !!
When the issue is transitioning from a state “To Do“ to the state “In Progress“:
The status is :To Do The status is :In Progress
Notice that even if we are in the same transition, the status is not yet updated (it’s the next action in the list of post-functions). The same may happen for custom fields or system fields, so it is recommended to always move the SIL post-functions last in the chain!
Contents