Semantics of Equals operator with multi-select fields?

[Stephan Gehring]

Hi,

I have a custom field (customField) where the user can select multiple values (value1, value2, value3). I further have two tasks with that custom field:

• Task 1: customField = {value1}
• Task 2: customField = {value1, value3}

and a Jira query containing

• ... AND customField = value1 AND...

The semantics of the equals operator in the Advanced search reference page is described as 

• The "=" operator is used to search for issues where the value of the specified field exactly matches the specified value.

My expected result for this query was therefore only {Task 1}, but Jira actually delivers both {Task1, Task2}. The equals operator in this case appears to be more of a set inclusion test than a set match.

Questions

• What is the exact semantics of the equals operator in Jira searches?
• How can I get Jira to deliver the exact match for multi-select fields, i.e. to deliver only items which exactly match a single value?

Thanks!

[Nic Brough -Adaptavist- · Accepted solution]

I'm not sure why you would think this.  The equals value is not a set inclusion, you're doing that with the set you defined in the values.

Equals means equals.  Does this issue have value X?   If you define X as a set, then obviously it could match several times.  = means "or" in boolean logic.

To do your "exact match", you will need to exclude.  Jira doesn't have an XOR function, so you'll have to do it manually.  "field = X and field not in (y, z)"

[Stephan Gehring]

Thanks for the fast response!

To me a multi-select field is a representation of a set. Assume a multi-select team field, where I can select zero or more teams. Say I have defined the multi-select myTeam field as having teams Red, Green, and Blue.

Then in an edit dialog I can select any one of the following team combinations

• [none]
• Red
• Green
• Blue
• Red, Green
• Red, Blue
• Green, Blue
• Red, Green, Blue

This, to me, is a set (I can select any subset of the three values).

If I now use equals to test for Red, i.e. "myTeam = Red", a Jira search will yield all issues which have any one of the following sets as value of the myTeam field:

• Red
• Red, Green
• Red, Blue
• Red, Green, Blue

and not just issues with the field set to Red (and only Red) which I would expect from the equals operator which Atlassian defines as

• The "=" operator is used to search for issues where the value of the specified field exactly matches the specified value.

If for an issue I choose all 3 teams, then the value of the myTeam field in that issue would be Red, Green, Blue. And to me, the value Red is not the same as the value Red, Green, Blue.

You state above that equals means "Does this issue have value X" which to me is testing whether value X is a member of the set.

Thanks for answering the "exact match" question, which for the example above would be

• myTeam = Red AND myTeam NOT IN (Blue, Green)

[Nic Brough -Adaptavist-]

That's my point, the = operator has exactly matched it, the field contains that option.  The fact that the field may contain other options is irrelevant to =.

If you wanted an "exact match on all content", then you would need a way to enter an array of options in JQL, and to use == instead of =.  You'd also need to get the array in the right order, the order in which the options happen to be stored in the field.  Not a lot of us have much use for that.

[James Guerin]

Yeah, not sure why this is a remotely acceptable answer. @Stephan Gehring is 100% right. 

= is not equals in this case
= means includes for multi selects

> That's my point, the = operator has exactly matched it

It has not EXACTLY matched it, it matched within a set of options. 

A = A > True (Exact Match)
A = A and B > Bogus Match in JQL

Even putting quotes doesn't work 

= "A" returns "A and B"

== also doesn't work

You should absolutely be able to do an exact match on a multiselect field without the need for NOT. Order has no bearing here. Any search should be smart enough to ignore order on a multi select for exact matches.

If I search for field = A and B

I should see results for
A,B
or
B,A
but NOT
A,B,C
and NOT
C,B,A

One of the many ways JQL is extremely limited / goes against normal search expectations. (i.e. sucks)

[Nic Brough -Adaptavist-]

It's an acceptable answer because it is correct, albeit it needs to be read with the follow-up comments.

The bit that matters there is If you wanted an "exact match on all content", then you would need a way to enter an array of options in JQL.

The = is logically correct - if I have a field with "red", "green" and "blue" set in it, then field = red is true because the field is red.  It does not matter that it is also green and blue.

Think of the questions in natural language:

• Is the field red and green?  Yes it is.
• Is the field red? Yes it is
• Is the field red and green, but not blue?  No

But with your logic:

• Is the field red and green?  No.
• Is the field red? No
• Is the field red and green, but not blue?  No

Problem is, now two of those No's are wrong, and you are forcing people to phrase the questions as

• Is the field red and green, but not blue?
• Is the field red, but not green or blue?

Humans do not want to have to think like that, most of us work best with "is it red?  Yes it's red, you don't care that it's blue and green as well, you asked about red".  The handful of people who do need an exact search usually understand that, and have no problem with "and not X"

And we are not good at "not", and we don't have a word to cover one of the four base boolean logic gates.  In English, we use inflection, situation, and intuitive theory of mind, to differentiate between XOR and OR questions.   

For example "is the traffic light red or green?" - the questioner is asking an XOR question because they do not expect it to be both red and green at the same time.  The logical answer is "yes" when the light is green or red, but also when it is green and red at the same time.  The person answering it will intuitively hear it as an XOR and explain - they'll say Red, Green, Amber, Red & Amber, or "it's broken".

But if you ask "Is my chameleon red or green?", a computer will say "yes" if the chameleon is red, green, or both.  It's an OR question.  The extrapolated answers a human would give would probably be along the lines of neither, red, green, both, a description of the actual (not red or green) colour(s), or in my case "I think it might be cruel to put your chameleon on a tartan, and please step away from the glitter"

In both cases, the human used the context to extrapolate what the questioner really needs to know.  They are intuiting the follow up questions, or understanding the question has more meaning.  Computers can't do that, they need to be asked for a binary clear yes or no answer. (and yes, that still includes most AI at their heart, although they would be able to answer my simple examples fine - there's no theory of mind in LLMs.  Yet.)

Humans don't think in XORs most of the time.  field = X is an "or" to most of us.

(I agree with you on the sort, it's trivial to code for, but fortunately, you don't need to)

[Filip Sagen]

I just stumbled upon this question and I have the same question but about the full set. I get the way to sort out those values where only "Red" is selected but is it at all possible to make a query that returns issues where only "Red, Green, Blue" is selected? not any other combination of subset?

[Nic Brough -Adaptavist-]

Yes, you can use the AND operator to join clauses.

Team = Red and team = green and team = blue

will satisfy that particular query, although you will need to add more if you mean "only when an issue has red green and blue"

That query will return issues that have (say) red, green, blue and yellow set.  You'd need to add "and team != yellow" to my first query to drop those issues.

[Filip Sagen]

Yes, thank you! but if i want to exclude those issues that have only red and green and not blue, it seems more difficult.

The reason is to make bulk changes on that particular field, e.g. :

issue 1-50: red, green, blue
issue 51-100: red, green

If I want to add a new team, yellow, but only to issue 1-50, it seems difficult to filter out those issues.

I guess I could check-box my way through a list of just 100 issues but more than that its starting to become a pain...

[Nic Brough -Adaptavist-]

There's two parts to this.

"colour = red and colour = green and colour =blue" will return issues 1-50, it will ignore 51-100.  So you can use that to do bulk-edit and add yellow to them.

The other part is a place for the "not" operator;   If you ran a filter for "colour = red and colour = green and colour !=blue", then you would get issues 51-100 only!