JJUPIN Latest - This documentation describes the plugin usage and configuration.
Download the latest version of the plugin and try it along reading.

Skip to end of metadata
Go to start of metadata

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:


Modifying Issues


You should 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 postfunction only.



Your SIL program will be saved on the disk in the folder specified in the configuration. 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.

Return codes:

Returns codes are different for validators, conditions and postfunctions

For validator:

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.

For condition:

Just tell JIRA this condition is not fullfiled.

For postfunctions:

return ends the program, any values are ignored.



When writing postfunctions, conditions or validators for the "Create issue" transition, make sure 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 postfunctions after all standard postfunctions.

See also: