Use cases for validators
This section has use cases which help you in understand the usage of Validators provided by JMWE.
On this page:
- 1 Field has been modified validator
- 2 Field is required validator
- 3 Comment required validator
- 4 Field has single value validator
- 5 Previous status validator
- 6 Parent status validator
- 7 Scripted (Groovy) validator
- 7.1 Block the creation of a Bug if no Attachment is provided.
- 7.2 Validate the Cascade select for values in parent and child select dropdowns
- 7.3 Block the approving of the Change request if it has no confluence page linked
- 7.4 Block the approval of an issue if there is no PDF attached either from before or added during the transition
- 8 Related Issues Status validator
- 9 Related Issue(s) validator
Field has been modified validator
This validator can be used to block the user from progressing to a destination status unless a field has been modified.
Sample use cases:
Validate the change in Resolution provided when closing an issue
Validate that the Fix Version/s has been modified when the resolution is "Fixed"
Field is required validator
This validator can be used to ensure that a field has a value during a transition.
Sample use cases:
Validate the Affects Version/s and Assignee fields for a non-empty value on creating a Bug.
Comment required validator
This validator can be used to force the users to enter a comment while transitioning to destination status.
Sample use cases:
Validate that a comment is entered when rejecting a Bug fix.
Validate that a comment is entered when the resolution is "Won't Do"
Field has single value validator
This validator can be used to check that a multi-valued field does not have more than one value during a transition.
Sample use cases:
Validate the Fix Version/s for a single value on an issue when the issue is fixed.
Validate that the Component/s field has only one value if the issue type is Story
Previous status validator
This validator can be used to stop the user from transitioning to a status unless the issue has previously been in a specified status in the workflow.
Sample use cases:
Block the transition of an issue to Close status if it has not been approved.
Parent status validator
This validator can be used to stop the user from transitioning to a status unless the issue's parent has been in a selected status in the workflow.
Sample use cases:
Block the trigger of "Start Progress" on subtasks until its parent is approved.
Scripted (Groovy) validator
This validator can be used to perform a validation with a groovy expression. Based on the result of the expression, the user is either allowed or blocked to transition to the destination status.
Sample use cases:
Block the creation of a Bug if no Attachment is provided.
Validate the Cascade select for values in parent and child select dropdowns
Block the approving of the Change request if it has no confluence page linked
Block the approval of an issue if there is no PDF attached either from before or added during the transition
Related Issues Status validator
This validator ensures that the current issue's related issues (such as linked issues, Stories of an Epic, Epic of a Story, subtasks of an issue, issues returned by a Groovy script or a JQL search, etc.) are in one of the specified statuses.
Sample use cases:
Block the transition of the Epic to Closed status, if its stories aren't closed.
Related Issue(s) validator
This validator ensures that a link to one (or more) issue(s) from the current issue is being created during the transition, and/or that existing and/or newly related issues (such as linked issues, Stories of an Epic, Epic of a Story, subtasks of an issue, issues returned by a Groovy script or a JQL search, etc.) have certain characteristics.
Sample use cases: