"Search syntax for text fields" the default boolean operator is both AND and OR and precedence weird

m-metz

On all versions of the help document for JIRA "Search syntax for text fields" https://confluence.atlassian.com/jirasoftwarecloud/search-syntax-for-text-fields-764478343.html it says 

Query terms

A query is broken up into terms and operators. There are two types of terms: single terms (e.g. "hello") and phrases (e.g. "hello dolly"). Query terms in Jira are not case-sensitive. Multiple terms can be combined together with Boolean operators to form a more complex query (see below). If you combine multiple terms without specifying any Boolean operators, they will be joined using AND operators.

But then later says:

OR

The OR operator is the default conjunction operator. This means that if there is no Boolean operator between two terms, the OR operator is used. The OR operator links two terms, and finds a matching document if either of the terms exist in a document. This is equivalent to a union using sets. The symbol || can be used in place of the word OR.

So which is it supposed to be?

 

I was trying with this query:

summary ~ "moves (CMR OR CMRS OR Morning Report)"

and it got treated like

summary ~ "moves AND CMR OR moves AND CMRS OR moves AND Morning OR moves AND Report"

summary ~ "moves AND (CMR OR moves) AND (CMRS OR moves) AND (Morning OR moves) AND Report"

Whereas when I tried:

summary ~ "moves (CMR OR CMRS OR Morning OR Report)"

It got treated like this:

summary ~ "(moves AND CMR) OR (moves AND CMRS) OR (moves AND Morning) OR (moves AND Report)"

Which is what I wanted.

The point is, sometimes the (space) is behaving like an AND, and sometimes like an OR (within parentheses, it is an OR, but when joining parentheses, it is an AND)

Also, the grouping behaves strangely in the text field search, it did OR grouping in

summary ~ "moves AND CMR OR moves AND CMRS OR moves AND Morning OR moves AND Report"

but in JQL

status=resolved AND project="Teams in Space" OR assignee=captainjoe

it does AND grouping

(status=resolved AND project="Teams in Space") OR assignee=captainjoe

but to be honest I get just strange behaviour when I use ANDs and ORs without parentheses.

These give the same results

(CMR OR CMRS) AND moves

moves AND (CMR OR CMRS)

These return different results

CMR OR CMRS AND moves

returns 1 result and acted like "CMRS AND moves"

moves AND CMR OR CMRS

returns 1681 results and acted like "CMR OR (moves AND CMRS)"

I feel like the grouping for text fields and the default boolean (AND outside of or if there are no parentheses, and OR inside parentheses) should be clarified on https://confluence.atlassian.com/jirasoftwarecloud/advanced-searching-764478330.html or just specify to always use parentheses when using AND and OR.

I use JIRA 7.1.3 https://confluence.atlassian.com/jirasoftwareserver0713/advanced-searching-965542847.html

Earl McCutcheon

Hi there,

Thanks for pointing this one out and Yes there is a discrepancy there and the second quote is incorrect, when doing a basic search when no boolean is used it is an AND not OR between two terms as teh expected value, and this one overall is a bit more confusing as there is a second issue occuring as well which looks to be a bug and overall compounding the expected behavior confusion from the complex semantic adherent wording with very specific terminology to the outcomes.

What looks like a BUG here is in the grouping as you noted where the grouping is looking like a mix of AND and OR for the odd behavior passing multiple Boolean variations into play as you are combining Terms, Phrases and Groupings into a single action via a distributive property and your examples are also showing some crossover with an additional Opperator being the "+" or some nested bracketing in the advanced search vs basic search and there is some overlap where it comes down to a distinction of the phrases inside the grouping causing alternating behavior or quotes would be required to distinguish the compound word as a phrase vs a term. 

Overall the BUG appears to be that the terms inside the parenthesis are being defaulted to a "+" operator rather than the AND that it should be.  The note about the OR operator being default is incorrect, we are still needing to do a bit of testing on this to verify everything against the code for this behavior and I created the following BUG report to track the Boolean error.

• https://jira.atlassian.com/browse/JRACLOUD-72542
• https://jira.atlassian.com/browse/JRASERVER-69650

And the following Documentation update request's to track updating all the docks in both cloud and server versions to reflect the correct AND vs OR notations:

• https://jira.atlassian.com/browse/JRASERVER-69649
• https://jira.atlassian.com/browse/JRACLOUD-72541

The First quote you listed is correct and below is a detailed breakdown on the expected behavior:

Query terms

A query is broken up into terms and operators. There are two types of terms: single terms (e.g. "hello") and phrases (e.g. "hello dolly"). Query terms in Jira are not case-sensitive. Multiple terms can be combined together with Boolean operators to form a more complex query (see below). If you combine multiple terms without specifying any Boolean operators, they will be joined using AND operators.

The Key focus point is if you "combine multiple terms", First point "A query is broken up into terms and operators." but it also notes specific to determining the two forms of a Term which are a Single Term or a Phrase as two differing types of terms, where a single term or a single word can be outside quotes and recognized, but a phrase needs to be inside quotes to define that exact phrase which is technically any compound word converted to a term, using the EXE from the doc in basic search using a text search for hello dolly no quotes is looking at two separate terms:

This formatting too is something specifics to basic search and you can can switch back and fourth between basic and advanced to see the modifications being applied here and this is effectively text ~ "hello dolly"  in Advanced search but as no boolean is added it is looking for hello AND dolly meaning that both words need to be found in the issue but not in that specific order so a issue with "dolly hello",  "hello some other words dolly" , and "hello dolly" would all get a hit in the result set but issue that contain just the word Hello or just the word dolly will be excluded.

Now lets flip that to a Phrase putting "hello dolly" in quotes in basic search:

Switching to Advance again we see now some backslash "\" modifiers displaying: text ~ "\"hello dolly\"" and these modifiers are defining the two previously individual Terms as a compound term or a Phrase so that only the exact phrase of hello dolly will be returned but occurrence where hello and dolly are both present but not directly stacked as that phrase will be excluded.  It Must include that exact phrase when quoted or its an AND

As for the secondary quote this part is incorrect and the default is not the "OR" operator but rather the "AND" operator the following statement in BOLD is incorrect and the OR value must be manually inserted:

OR

The OR operator is the default conjunction operator. This means that if there is no Boolean operator between two terms, the OR operator is used. The OR operator links two terms, and finds a matching document if either of the terms exist in a document. This is equivalent to a union using sets. The symbol || can be used in place of the word OR.

Looking at your Query against summary in basic search, the grouping which are the items in the parenthesis "()" you get the AND operator between morning and report as there is no boolean between the two terms which lines up with expected behavior and quote from the documentation so your query:

moves (CMR OR CMRS OR Morning Report)

Converting to advanced search would look like this 

summary ~ "moves (CMR OR CMRS OR Morning Report)"

But should be translated to the following when the distribution of the variables come across: 

summary ~ (moves AND CMR) OR (moves AND CMRS) OR (moves AND Morning) AND (moves AND Report)

HOWEVER as noted in the BUG above is being treated with a + or double bracketing at the section :

OR (moves AND Morning) AND (moves AND Report)

treating this section with the logic of either

OR (moves AND Morning) + (moves AND Report)

OR

OR ((moves AND Morning) AND (moves AND Report))

So overall conclusion on the documentation mix up and the Discovered BUG is that the AND is defiantly the operator that should be present as the default not the OR, so manually inserting the OR operator or the AND operator as needed is the optimal workaround when nesting terms in a group.

And thanks again for the info you provided her it was really helpful tracking down the inconsistencies in the behavior.

Regards,
Earl