Writing Post-Functions (Actions)

Post-functions are the real action actions on the workflow , and they are executed in the final stage to of 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 post-function may be as simple as:

assignee = currentUser();

… or as complex as you might want itOr, add complexity to meet a specific requirement.

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

Parameters

On cloudthe Cloud, the only derived parameter we could derive is the post-function own idID. 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.

An example is below:

… and And the following 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 will be is (on the ERROR level, where we the message was 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 Even if the script is the same, the different integration points will generate unique ids IDs (on different transitions and workflows). Therefore, you may use this strategy to apply small changes on to the logic depending on where you areyour location. However, these ids IDs are not portable from install to install.In any case, we hope the above will open the doors for reusability of

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

Scripts are executed within the issue context.

Return Codes For Post-Functions

return;

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 a good idea it’s recommended 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 new issue has not been indexed if the post-function is applied to the ‘create’ “create” transition then the new issue has never been indexed and the . Also, the index does not exist until this the index step has run runs for the first time, and no data may exist for the issue at this point. That is why . For these reasons, it is always best for the post-function to be after all the standard post-functions.

As an example, we will reuse the above configuration example of the configuration:

… but However, this time we will , let’s 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 , or system fields, etc so please, so it is recommended to always move the SIL post-functions last in the chain!