How is JQL's binding of OR actually working

[Jon Smalley]

For the record, this is a 1st-time post from a long-time user. I've written a lot of JQL, and have learned to avoid using OR.  The only reliable why I've found is to duplicate clauses so that everything on both sides of the OR is independent of it.  The use of parenthesis is ineffective to change this.  I could be missing something, but this silliness has reached my tipping point!

This query incorrectly returns 210 items: 

(resolutiondate >= 2021-09-28 AND resolutiondate <= "2021-12-20 23:59") AND (project = MPH AND "Critical Response Level" in (Critical, Sensitive) AND "Morpheus ART Team" = "Internal Transfers Team") OR (issuetype = Inquiry AND assignee was in (/*list of team members removed*/))

But, by only duplicating the resolutiondate clause, this query correctly returns 4 items:

(resolutiondate >= 2021-09-28 AND resolutiondate <= "2021-12-20 23:59" AND project = MPH AND "Critical Response Level" in (Critical, Sensitive) AND "Morpheus ART Team" = "Internal Transfers Team") OR (resolutiondate >= 2021-09-28 AND resolutiondate <= "2021-12-20 23:59" AND issuetype = Inquiry AND assignee was in (/*list of team members removed*/))

[Nic Brough -Adaptavist- · Accepted solution]

I do not think that the OR is the problem here, it's the order in which the clauses are read - I think you're expecting the clauses to be joined differently to the way they actually are.

When you don't enforce precedence with parenthesis, Jira, will read left to right.  

I like simplifying these down to make them more easily readable/explainable.  Your 210 result query makes sense to me, because it comes down to

• (resolution date) and (project and level) and (team) or (issue type/assignee)

Which then could be simplified again as 

• (resolution data and project and level and team) or (issuetype/assignee)

The second query simplifies differently:

• (resolution date and project and level and team) or (resolution date and issue type and assignee)

So, the OR here is not at fault.  It's that you are ORring different things.  Both of your queries are looking at resolution date, project, level and team in the same way,  on the left-and side of the OR, but the right hand side is very different.  The first one is selecting every issue in your system that matches the issue type and assignee question.  The second one does the same, but also includes your resolution date question.

I am not going to claim that I'm any good at building or understanding JQL directly.  The stuff I've just written took ages because I had to go over it carefully and simplify it for my reading.  I suspect I might have failed one of the Jira exams if I'd had to actually do it, because it was heavy on the JQL and I don't think I would have had the time to do the break-downs like I have here, but there is a simple piece of advice that works

If you want to build a JQL question that uses an "and" and an "or", always use parentheses in it to force it to evaluate in the order you want.

[Bill Sheboy]

Hi @Jon Smalley 

Yes, and...to Nic suggests: 

IMHO, JQL has some challenges but it seems consistent in the area you note.  When in doubt, please try something like this to confirm your query matches your desired outcome:

• build your query up piece by piece, testing as you go
• start with what is "true" for every issue you want to return, joining those with AND.  For example;

project = myProject
 AND issueType = Story

• wrap that clause in parenthesis to force evaluation ordering.  For example;

( project = myProject
   AND issueType = Story )

• when you need an OR clause, add it as another parenthesis-wrapped OR clause first.  For example;

( project = myProject
   AND issueType = Story )
 AND
( labels IN ("Marketing")
   OR labels IS EMPTY)

Kind regards,
Bill

[Jon Smalley]

Thanks Nic & Bill,

Great answers about the fundamentals of boolean logic - sorta like John Wooden and shoelaces.  My lapse was missing parens (in bold below) to force evaluation of the OR first so its result is ANDed with the other.  In Nic's simplified form, the needed result is given by:

• (resolution date) and ((project and level and team) or (issue type and assignee))

Interestingly, both this revision and my original workaround both get the "red X" warning, yet execute correctly. Perhaps Bill, this is one of JQL's challenges you referred to.

[Nic Brough -Adaptavist-]

I really want to say that I was not trying to teach anything about boolean logic to you here.  You had that nailed, but not quite which particular rule-set Jira's JQL subscribes to.  Although to be totally Boolean, there is only one right way to interpret the rules (which we all did here)

Annoyingly, it does feel like Jira's coders don't talk on this one - a search that works, but throws a red x, suggests two different teams executing or validating searches.  We just want them to work and answer the question!

[Bill Sheboy]

Hi, Jon.

Seconding Nic's follow-up, as I was trying to offer some diagnostic steps.  My apologies if that was perceived otherwise.

Regarding other JQL challenges, listing too many often leads to "spirited responses" from our vendor's team.  Some I watch for are: non-deterministic behavior of null versus empty fields, sorting issues with ORDER BY, gaps in field attribute access, and possibly side-effects from a couple of versions of the JQL handling (advanced search and the new issues view).

Kind regards,
Bill

[Jon Smalley]

Gents, I have found each of your responses of high quality and instructive. Sincere and genuine thanks! My fundamentals comment was due to the fact going back to order of precedence was necessary for me to spot my error.