Advanced search (Server / Data Center)
Here is a list of operators that you can use in the Advanced search:
IN operator
To write your JQL queries, MLCS fields can be searched using the IN operator or a JQL function defined by the add-on, "MultiLevelCascadeOption()".
The IN operator produces a result set which is wider than the one we get using the "MultiLevelCascadeOption()" JQL function: it will hit all the cases where the given sequence of option values appears among the selected ones.
Example:
Given an MLCS custom field "Place" with an option structure like:
Europe
> Italy
> France
America
> Mexico
> USA
then the JQL query
Place in (America,USA)
will retrieve all the issues such that "Place" evaluates to anything that contains "America" followed by "USA", regardless of the depth of the options: this means that, if we add "America" as a child option of "Italy", and "USA" as a child option of the second "America", so that the option structure is made into
Europe
> Italy
> America
> USA
> France
America
> Mexico
> USA
then the issues such that "Place" evaluates to "Europe - Italy - America - USA" will be retrieved (while "MultiLevelCascadeOption(America,USA)" would retrieve only the issues in which "America" is the root option, followed by "USA")
The IN operator also supports the "None" keyword, so
Place in (Europe,None)
will retrieve all issues where "Europe" is selected but no deeper options are chosen.
The IN operator can be also used with option IDs, but the None keyword won't work in that case (it will be ignored).
IS operator
The IS operator is used to find out the issues that have the MLCS custom field set to any value.
In our example, the two possible queries using IS are:
Place is EMPTY
which will retrieve all the issues such that "Place" is not set at all;
Place is not EMPTY
which retrieves all issues such that "Place" is set to any value.
JQL function (DEPRECATED)
The function MultiLevelCascadeOption() gets one or more comma-separated parameters, that can be option IDs and/or values
This function is deprecated in favor of the IN operator and will be removed in future releases
Examples:
fieldName IN MultiLevelCascadeOption(100003, 100012)
retrieves the issues where the fieldName MLCS custom fields have the option of id "100003" selected on the first level and its child option of id "100012" selected on the second level, regardless of what is selected on the deeper levelsfieldName IN MultiLevelCascadeOption(100003, 100012, None)
retrieves the issues where the fieldName MLCS custom fields have the option of id "100003" selected on the first level and its child option of id "100012" selected on the second level and no option is selected on the deeper levelsfieldName IN MultiLevelCascadeOption(optionValue1, optionValue2)
retrieves the issues where the fieldName MLCS custom fields have the option of value "optionValue1" selected on the first level and its child option of value "optionValue2" selected on the second level, regardless of what is selected on the deeper levels (if we add "none" as last argument, issues where anything is selected on the third level will be excluded)fieldName IN MultiLevelCascadeOption(optionValue1, 100012, None)
retrieves the issues where the fieldName MLCS custom fields have the option of value "optionValue1" selected on the first level and its child option of id "100012" selected on the second level and no option is selected on the deeper levels
Although option values are not unique across JIRA, sibling options cannot share the same value. Therefore, someField in MultilevelCascadeOption("something", "somethingElse", "somethingFurther")
is unambiguously defined. Ambiguity arises only if an MLCS field has two options where one option's value equals the other's ID. Typically, the option hierarchy ensures unique interpretation for queries. In rare cases of ambiguity, a warning dialog will appear.
If you call the function, consider using IDs instead of values if you have to deal with option values which are numbers (IDs are always unique).