๐Ÿš€ Ultimate Condition & Validator

A Smarter Way to Build Jira Validators ๐ŸŽ‰

Weโ€™ve been working on a more flexible way to build conditions using Jira Expressions, and that led to Ultimate Validator. It lets you use most of the power of Jira Expressionsโ€”but without writing code. Instead, you build conditions through a simple UI.

How Ultimate Validator Works

After selecting a sourceโ€”such as a field or the current userโ€”a list of operations appears. Each operator leads to the next until you reach a terminal operator that requires a value. The Jira expression preview is generated in real time, so you always know exactly how your condition worksโ€”no more guesswork.

Hereโ€™s what it looks like:

Ultimate Validator configuration validating that every attachmentโ€™s file name ends with .pdf using no-code string operators in a Jira workflow validator.
Validate that all attachments have a .pdf file extension using string operators in Ultimate Validator.

Common Use Cases

Here are some common scenarios where the Ultimate Validator simplifies complex conditions.

Conditionally require mandatory fields based on other field values

Jiraโ€™s built-in Field Required validator doesnโ€™t allow conditionsโ€”you either require a field for every transition or not at all. But often, you need a field to be required only when certain conditions are met.

With Jira Expressions, this is possible. For example, if you want the Root Cause field to be required only when Resolution is set to Fixed, you could write:

issue.resolution?.name == 'Fixed' ? issue.customfield_10126 != null : true  

Alternatively, you can achieve the same result using the || (OR) operator. In this case, you'd need to invert the condition: allow the transition when the resolution is not 'Fixed', or require the "Root Cause" field otherwise:

issue.resolution?.name != 'Fixed' || issue.customfield_10126 != null  

Ultimate Validator lets you set this up easily through the UI, with no need to write code.

Ultimate Validator interface demonstrating how to use OR logic to make fields conditionally mandatory in Jira workflows without writing any script.
Use OR logic in Ultimate Validator to conditionally require mandatory fields based on other field values.

Handling Rich Text Fields in Jira Expressions

If you're concerned about the recent changes in the multi-text field format during Issue Transition, don't worryโ€”the plainTextValue helper automatically handles the different formats for you.

There are a few key points to keep in mind when writing Jira Expressions manually. First, almost every field can be null, so you typically need to check for null before performing operationsโ€”otherwise, you may encounter a Syntax Error during execution.

Counting characters in Short Text fields is straightforward, but Rich Text (Paragraphs) can be tricky. Most rich text fields are stored as ADF (Atlassian Document Format) objects, meaning they need to be converted using new RichText(value) to access the .plainText property. However, some fieldsโ€”like Description or Environmentโ€”are exceptions, as they are already converted when used in expressions.

Ultimate Validator takes care of these complexities, ensuring that your validation works correctly without requiring manual adjustments.

Ultimate Validator UI example showing how to restrict maximum paragraph length in a Rich Text field using the length and less than operators in a no-code Jira workflow rule.
Limit the maximum paragraph length in Rich Text fields using the length and less than operators in Ultimate Validator.

Counting Items in Multi-Select Fields

With the Count operator, you can validate how many items have been added or selected in multi-value fields, such as:

  • The number of attachments on an issue.

  • Whether only one option is selected in a multi-select field.

  • Ensuring a required number of checkboxes are selected.

  • Requiring a minimum number of Versions, Components, or Labels.

Ultimate Validator UI showing how to enforce attachment count or checkbox selection using the โ€œcountโ€ operator in a no-code Jira workflow validator.
Enforce a required number of attachments or selected checkboxes using the count operator in Ultimate Validator.

Validating Child and Linked Issues

Jira Expressions allow you to check relationships between issues. The key properties are:

  • subtasks โ†’ Returns an issueโ€™s sub-tasks.

  • stories โ†’ Returns an Epicโ€™s child issues (excluding sub-tasks).

  • childIssues โ†’ Returns both child issues and sub-tasks.

You can also test issue links (e.g., โ€œblocked byโ€) and parent issues. However, for linked issues validation, we recommend using the dedicated Linked Issues Condition & Validator.

Ensure Time Is Logged on an Issue or Its Sub-Tasks

To prevent issues from progressing without logged work, you may want to require that time is recorded either on the issue itself or one of its sub-tasks.

Ultimate Validator UI example showing how to require time tracking by validating that either the issue or one of its sub-tasks has Time Spent filled in.
Validate that time is logged on the issue or any sub-task using a simple OR rule in Ultimate Validator.

Ensure Child Issues Are Closed Before Transitioning the Parent

When requiring all child issues to be closed before the parent moves to a completed status, it's best to use status categories rather than individual status names. Jira has three status categories:

Category name
Category key
Category id

To Do

new

2

In Progress

indeterminate

4

Done

done

3

With Ultimate Validator, you donโ€™t need to deal with categories IDs or keysโ€”just pick the right option from the dropdown.

Jira workflow validator setup in Ultimate Validator to ensure all child issues are in Done status before allowing the parent issue transition.
Ensure all child issues are completed before transitioning the parent by checking status category in Ultimate Validator.

Properly Validating Cascading Select Fields

The built-in Field Required validator only checks if the parent option is selectedโ€”it doesnโ€™t check the child option. This means a transition can still go through even if the child selection is missing, which isnโ€™t always the expected behavior.

This is a known issue (JSDCLOUD-6199), but Ultimate Validator provides a child option operator, allowing you to ensure that the child option is always selected.

Ultimate Validator screenshot demonstrating how to enforce selection of both parent and child options in a cascading select field using the child option operator.
Ensure both parent and child options are selected in a cascading select field using Ultimate Validator.

Checking if an Issue is in an Active Sprint

You can check various sprint properties in Jira Expressions, such as start date, end date, completion date, and state.

To check if an issue is in the current sprint, validate the sprint state:

  • "active" โ†’ Sprint is in progress.

  • "future" โ†’ Sprint is planned but not started.

  • "closed" โ†’ Sprint has ended.

With Ultimate Validator, you can easily enforce sprint-based conditions without needing custom expressions.

Ultimate Validator configuration for checking if an issue is part of an active sprint by validating internal sprint state properties in a Jira workflow condition.
Ensure both parent and child options are selected in a cascading select field using Ultimate Validator.

Ensuring an Issue Is Not Associated with Released Versions

With Ultimate Validator, you can test system fields like Affects Versions, Fix Versions, or custom version pickersโ€”not just by version name, but also by version properties such as description, start and release dates, and states like archived or released.

Ultimate Validator enforcing that issues are not linked to released versions, validating fix versions using no-code workflow rules in Jira.
Prevent issue transitions if any selected fix version is already released using Ultimate Validator.

Tip: If the version field can be empty, include a clause to allow empty values; otherwise, start directly with the check for released versions.

Last updated