This very powerful post function can be used to update a single issue field according to a set of rules.
You can use this function to construct multiple "if → then" rules.
Once you have defined the source field, a rule and a value you have constructed the entire if clause.
The next step is to define, which value the target field will be updated to, if the values match. This is the then part of your rule.
If used in the create transition, they need to be placed after the “Create issue initially” post function
Configuration
Select the field that will be analyzed by the defined rules. The combination of this source field and the source value, as specified in each rule, builds the if part.
Even though this parameter is mandatory, the selection is irrelevant if you choose to base your rule on a Logical expression.
Select the field to be updated according to the rules.
The rules will be processed in order. The first rule matching the given expression will update the target field.
Define the rules for updating the target field and the corresponding target field values.
Once a rule is matched, its associated value will be parsed or calculated and copied to selected target field, and the rest of the rules will not be processed.
If the selected target field is of type number, date, date and time, the associated value should be a number or a mathematical/time formula. Learn more about Numbers and working with Dates, times and time zones.
Other data types like users, issue status, issue priority and issue resolution require values of corresponding suitable types.
Rules can be written as line separated text in Expert mode or using the easy way in Table view.
You can choose between the following options:
Option | Description |
---|---|
Text comparison | Choose this option if you want to compare the value of the specified source field with another text value. |
Logical expression | Choose this option if you want to construct a logical rule using the Logical mode. Once set up, you have to define, which value the target field will be updated to if the expression returns true . |
Regular expression | Enter a valid regular expression and optionally use field codes to to specify your rule. This expression will then be evaluated against the selected source field. |
Examples:
IF | THEN | Output | |||
Source field | Mode | Source field value | Target field | Target field value | Description |
---|---|---|---|---|---|
Priority | Text comparison | High | Assignee | a.agrant | If the issue priority is High, the issue will be assigned to a.grant. |
Priority | Text comparison | Low | Assignee | d.jones | If the issue priority is Low, the issue will be assigned to d.jones. |
You can write three types of rules as in the following options:
Option | Description |
---|---|
Text comparison | Add the prefix <l> if you want to compare the value of the specified source field with another text value. The text value should be put in round brackets followed by the target value. Example: l(<comparableText)targetValue |
Logical expression | Add the check expression in square brackets if you want to construct a logical rule using the Logical mode. It should be followed then with the value the target field will be updated to if the expression returns [<logical expression>]targetValue |
Regular expression | Enter a valid regular expression in brackets and optionally use field codes to specify your rule. This expression will then be evaluated against the selected source field. If you want to ignore case, then add the prefix <i>. <optional>i(<regEx>)targetValue |
The prefix <a> is used to indicate advanced parsing mode for the target value in the rule.
Examples:
Refer to the old version of the postfunction for more examples.
Logical expressions are not analyzing the source field. Whereas text comparison and regular expression rules are checked against the source field value, logical expressions are independent of the source field value. Instead you will have to provide a logical expression using the Logical mode.
Alternatively you could use the Update or copy field values post function and set values using multiple conditional operators.
Option | Description |
---|---|
Write protection | Check the write protection option if you want to prevent a field to be updated, if it already has a value. If checked, only empty fields will be set. |
Evaluate all rules | Per default, JWT will stop evaluating the rules when the first rule matches (e.g. a source field value was identified according to a rule). If you check this option, JWT will evaluate all rules, potentially executing a different rule. The order in which the rules are specified matters in this case as JWT will go through each rule from top to bottom. Only applicable for multi-valued or temporary target fields. |
Update issue immediately | Choose to update issues immediately if you want Jira to fire a separate "Issue updated" event for any field change. This will also result in a dedicated issue history entry. |
The result of the logical expression must return a boolean value of either:
true
→ the post function will be executedfalse
→ the post function will not be executed
Using the conditional operator, even complex or multi-layered conditions can be constructed.
Make sure to learn more about defining logical expressions and browse through the various examples here: Logical mode
Make sure that the user running the post function has all the relevant permissions to perform the actions defined in the configuration (e.g. "Update Issues")!
If you want to keep track the actions being performed automatically, we suggest to create a dedicated JWT account, granted all relevant permissions, and use it in the Run as parameter to identify which changes have been made with JWT.
Use case and examples
Use case |
---|
No content found. |
If you still have questions, feel free to refer to our support team.