This validator ensures that a field is required. It will mark such fields with a red asterisk (*) on the transition screen.
In Jira you can use field configurations to make fields mandatory. But this will make the field required on every screen it appears. In most cases users do not have all required information when creating issues, even if the information is required later in the workflow.
With this validator it is possible to make fields mandatory during any workflow transition to make the process more user friendly.
All custom fields and most system fields are supported. See here for details.
Example usage:
Optionally you can define a Condition (choose from all available Conditions in system). The validation will only be validated if the Condition is met.
Example usage:
Note:
Please give us feedback for the conditional execution. We might add this feature to other Validators and Post Functions.
This validator can check if a certain field value matches a regular expression you define. It is quite powerful and its use cases range from a simple validation (where the user provided an exact value) to use cases where you check whether the user checked one or the other option in a cascading select list.
Parameters:
How are fields evaluated?
All custom fields and most system fields are supported. See here for details.
Examples:
Also available as Condition.
This validator enables you to compare two fields with each other.
Supported operators are:
Supported field types:
You can optionally compare with a value on the parent issue.
Both fields must be of the same type.
Note: For parent lookup, the validation will not fail if the issue has no parent (it is a subtask). This allows you to use the same workflow for parent and subtask issues.
This validator compares a date field with a fixed date or a variable expression like +7d.
Supported field types:
You can use a fixed date in format yyyy-mm-dd hh:mm or a pattern (days, weeks, months, years).
Examples:
This validator evaluates the current issue against a configured JQL expression.
Note: Data that has been currently changed during a transition can not be considered by a JQL expression, as these changes are not yet saved.
Additional configuration (optional):
Examples:
The possibilities with JQL are endless. We recommend reading the following article:
https://confluence.atlassian.com/jiracore/blog/2015/07/search-jira-like-a-boss-with-jql
A validator that compares fields against a fixed value.
Supported operators:
Supported comparison types:
Examples:
Supported Fields:
Note: To compare against an empty field, just leave the comparison value blank.
Note: To split several values, just use a comma to separate, additional quotes are not necessary.
Valid examples: "first long string value, second long string value" or "14, 42, 13.37" (quotes in these examples are just used to highlight the configured values)
Note: fields that aren't present do NOT get evaluated. That means, for example, if you configure a custom field of type "single select" to be equal a fixed string value and that custom field is not set at all, the validation will result as invalid. To support the validation even if the field is not set, you have to configure an additional required fields validator for that field.
If you tick the checkbox it will validate the value from the child to the parent issue. The validator does not check whether there is a parent available. |
Number Compare Validator is deprecated and replaced by the Field Compare Validator. Please update your existing configurations. Please note that the Validator is initially deactivated. You have to activate the module manually. |
Validates that currently logged in user is in any or is not in any of the specified project roles.
Example: Only a user who is in the role "Developers" or "Users" can execute this workflow transition.
Also available as Condition.
Validates that the currently logged in user is in any or is not in any of the specified groups.
Example: Only a user who is in at least one of the following groups "My Group", "jira-administrators" or "project-admins" can execute this workflow transition.
Also available as Condition.
A validator to ensure that the currently logged in user is set on one (or many) custom field(s) (on the current or parent issue).
You have three options:
Supported custom field types
You can also select group related custom fields. On validation the user will be checked, if she/he is member of the selected group (or at least one group, if multiple are selected).
This validator prevents users from creating sub tasks for different parent issue types. You can add this validator to the "Create" transition from the sub task and validate if the parent is of the configured issue type.
Validates that the parent's current status is a specific status.
There are several use cases for this validator. Find some examples listed below:
To configure the validator:
This Validator supports a user defined error message.
Also available as Condition.
If you want a user to change a value on a transition screen, then this Validator will get the job done for you.
All custom fields and most system fields are supported. See here for details.