Writing Validators, Postfunctions and Conditions
After you installed JJUPIN plugin, you should go to your JIRA's Administration->Workflows page and create a workflow, associated with a project. Since you cannot modify the workflow while it's active, you must create a draft workflow, as specified in the JIRA documentation, by pressing the "Create draft" link. The result should look like in the below excerpt.
Clinking on a transition will show the transition's conditions, validators and postfunctions.
You should always keep in mind that:
1. Whenever an issue advances from one state to another the postfunction will be called.
2. The transition is made possible only if the conditions are fulfilled. Therefore, a condition must return true or false to signal that the condition is fulfilled or not
3. The validators must validate the data before 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, JJupin is discarding modifications of the issues, allowing them to occur in the postfunction 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 postfunctions, press the corresponding add link, found at the top of the workflow management tab.
The following image shows the creation of a test post-postfunction:
After you'll press the "Add" button, you will be ready to write your SIL (in this case, a SIL postfunction)
By providing a meaningful name to your program and by pressing the "Add" button, you are now ready to extend your JIRA Workflow:
Returning into the transition screen, your newly added post-function will be reflected in the view:
Returns codes are different for validators, conditions and postfunctions
The first field tells us that we have failed, the second indicates the field, the third is the message that will be set on the user interface. 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). One can easily inspect the HTML source of the edit screen to see the "bare" name of a field.
Just tell JIRA this condition is not fullfiled.
return ends the program, any values are ignored.