One of the best features in Power Scripts™ is customizing workflows. Using the power of SIL, you can add conditions, validators, and post functions on any transition from your workflow.
Writing validators, post functions, and conditions
After you install Power Scripts™ for Jira, go to the Administration > Workflows page and create a workflow, associated with a project.
You can modify the workflow only while it's active, therefore you have to create a draft workflow by clicking the Create draft link.
The result should look like the image below.
Clicking a transition will show the transition triggers, conditions, validators, and post functions.
Keep in mind that:
- The post functions are called every time when a ticket advances from one state to another.
- The transition is made possible only if the conditions are fulfilled. Therefore, a condition must return "true" or "false" to signal whether the condition is met or not.
- The validators must validate data before the transition is fired. Subsequently, a validator is entitled to return "true" or "false" and optionally the field and the error message you want to show in the interface.
An important consequence of the above model is that conditions and validators should not have side-effects. In fact, Power Scripts™ for Jira is discarding modifications of the issues, allowing them to occur in the post function only but it cannot discard modifications made on another database, for instance, applied using the sql routine (see sql() routine for details).
To create conditions, validators and post functions, click the corresponding Add link at the top of the workflow management tab.
The following image shows the creation of a test post function.
After you click the Add button, you can write or reuse your SIL (in this case, a SIL post function) by going through the wizard steps below.
Click Next and write the code. In this case, we added a comment to certain linked issues.
The next step is just for confirmation.
You can create a new script or pick a script that was already created or even used for other purposes in the silprograms folder (or wherever those files are located, established by your configuration).
By providing a meaningful name to your program and by clicking the Finish button, you are now ready to extend your Jira workflow.
Return to the transition screen, you will see that your newly added post function is reflected in the view:
Avoid modifying issues in conditions and validators, as they are supposed to be read-only. Do not yield to that temptation! You should modify issue values (or create new issues, or change anything) in the post function only. In fact, SIL runs executes the validators and conditions in the read-only mode, discarding changes.
Starting with Power Scripts™ for Jira 4.0, your SIL program will be saved either on the disk in the folder specified in the configuration or in the database. The filename is obtained by removing any invalid characters from the program name you entered and appending a number to help you browse through different versions of the same file.
For the best experience, we recommend Google Chrome or Mozilla Firefox.
Returns codes are different for validators, conditions and post functions.
The first field tells us that we have failed, the second indicates the field, the third is the message that will be shown on the UI. For the moment, the filed name must be a "bare" name. That means that it should comply with the name given to the HTML objects displayed (e.g: for customfields it will be customfield_xxxxx). You can inspect the HTML source of the edit screen to see the "bare" name of a field.
For example, you can check whether certain fields were filled out during a workflow transition. To do that, use the hasInput routine.
Just tell Jira this condition is not fullfiled.
For post functions
return ends the program, any values are ignored.
When writing post functions, conditions or validators for the Create issue transition, ensure that the SIL program is the last step of the transition. This is necessary because we need Jira to create the actual issue and save it to the database using the input parameters before we can access it.
In general, it's a good idea to place your post functions after all standard post functions.
This view will help you browse through your workflow without having to open the program every time to see what it does.
On the first line we have the name of the SIL program. After that, you have a short description of the program, which you can write by commenting on the first lines (max. 3 lines) in your code. For example, the program you see on the right contains "//Your SIL code should go in here" on the first line.
Finally, you have the error notifier which tells you whether the program is correct. If there are any errors, open the program for a more detailed description of the cause. If the program is correct, this line will be blank.