Writing Post-Functions (Actions)

Post-functions are the real action on the workflow, and they are executed in the final stage to the transition. Here, you can add a script that will actually do something. They have no special requirements on returns and they always execute in the context of the transitioned issue.

A postfunction may be as simple as:

assignee = currentUser();

… or as complex as you might want it.

Unlike validators and conditions the post-function is the only place in the workflow where you are allowed to modify the issue!

Parameters

On cloud, the only parameter we could derive is the post-function own id. It is passed as the only one parameter in the execution of the script, allowing you to create decisions in your script based on it.

Example, be given the following configuration of the transition:

… and the following 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 will be (on the ERROR level, where we pushed our messages):

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

This is because, even if the script is the same, the different integration points will generate unique ids (on different transitions and workflows). Therefore, you may use this to apply small changes on the logic depending on where you are. However, these ids are not portable from install to install.

In any case, we hope the above will open the doors for reusability of your scripts.

Runtime User

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 other automation or addon which does not act as the triggering user, the current user may be null, in which case you will need to deal with it programatically.

Return Codes For Post-Functions

return;

return ends the program, any values returned by the script are ignored.

Order of the Post-functions

In general, it's a good idea to place your post functions after all standard post functions. This allows the issue to be re-indexed and the data to be stored in the issue correctly. If the post function is applied to the ‘create’ transition then the new issue has never been indexed and the index does not exist until this index step has run for the first time and no data may exist for the issue at this point. That is why it is always best for the post function to be after all the standard post functions.

Let’s see it at work. We will reuse the above example of the configuration:

… but this time we will modify the post-function script to read like this:

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, system fields, etc so please, always move the SIL post-functions last in the chain!