Validators are used to guarantee accuracy of existing issue data or data entered on a transition screen before a transition is executed.
Jira ships with built-in validators but those are limited. JWT for Jira Cloud extends that list by offering custom validators.
Jump right in and configure any of the available validators listed below. Each validator comes with built-in examples.
Use cases and examples
|Use case||JWT feature||Workflow function||Use case description||Complexity|
|Block a transition based on issue links|
Evaluate issue links and hide transitions based on the outcome.
|Block a transition based on sprint information|
Make sure that an issue is not in an active sprint.
|Block a transition based on the day of the week|
Block transitions on weekends or any other day of the week.
|Block a transition if a predefined field value has not been changed|
Evaluate a Date Picker field and block the transition if it has not been updated.
|Block a transition if some issues under an epic are not in a certain status|
Check whether an epic has all issues under it in a certain status.
This is particularly important if you want to block an epic as long as work is still being done on related sub-tasks.
|Check current issue status|
Check whether the current issue is in a particular status.
|Check for at least one component|
Require a at least one component.
|Check for unresolved sub-tasks|
Check whether the current issue has any unresolved sub-tasks.
This is particularly important if you want to block a parent issue as long as work is still being done on related sub-tasks.
|Check if an attachment was added recently|
Make sure that the current user has uploaded a attachment during a definite period of time.
|Check parent issue type|
Check whether the parent of the current issue is of a certain issue type.
This is particularly important if you want to reuse a workflow for multiple sub-task issue types but only want a transition to be available if the sub-task belongs to a certain user story or a bug.
|Check the number of times that a field has changed||Check the number of times that a field has changed.|
|Current user must be reporter|
Current user must be reporter.
|Due date must be in the future|
The due date must be in the future.
|Issue must have at least two attachments|
Require a at least two attachments.
|Make a fix version required and add a comment||Fields required or changed|
Require a fix version and add a comment.
This use case is valid for validators.
|Make the assignee required|
Require a non empty assignee.
|Resolution must be empty|
Not allow a resolution to be set.
|Validate an issue only if a comment is written during the transition|
Evaluate the comments and hide transitions based on the outcome.
This use case is only valid for validators as it involves making changes during a transition. An additional error message can be added.
Evaluate if a user has logged more than a certain amount of time in the latest worklog.