Thank for the good news!!

Could you please let us know which files we need change in Jira 5.1 to work out this issue.

This is HUGE!!! Thanks for the good news!

This is fixed and released to our onDemand releases. It will also be included in our upcoming 5.2 release

Mairead
PM JIRA

Yes, and while people like Luke and us are now content with our modified instances and thus cease prodding Atlassian to finally fix this silly problem, everyone else still has to suffer the bad search behavior and the resulting performance/stability problems - not fair

That comment was from a user taking matters into their own hands and modifying the source code for their own JIRA instance. This issue has still not been addressed by Atlassian.

I'm confused. In 4.4.3, it appears the search (as launched from the "quick search" box) still uses OR by default, despite this comment that seems to indicate otherwise..

Searching for "A B C" results in JQL:

summary ~ "A B C" OR description ~ "A B C" OR comment ~ "A B C"

and appears to return results that don't contain C at all, in any field.

In my opinion, the resulting JQL should be:

(summary ~ "A" OR description ~ "A" OR comment ~ "A") 
AND (summary ~ "B" OR description ~ "B" OR comment ~ "B") 
AND (summary ~ "C" OR description ~ "C" OR comment ~ "C")

This would mean all terms have to appear somewhere.

Forget the admin configuration... "AND" is correct and "OR" is wrong.

Volker, can you copy the information from the support ticket to this ticket, or at least list the file names where these changes were made?

In JIRA 4, all we needed to do was to change com.atlassian.jira.jql.query.LikeQueryFactory a little.

In JIRA 4, JQL uses the LIKE search on all text fields and only on text fields which allows us to easily limit the AND operation to selected fields. We added the following lines of code to the getQueries method which parses the query input and sets the operand:

if(fieldName.equalsIgnoreCase("summary") || fieldName.equalsIgnoreCase("description") ||
                fieldName.equalsIgnoreCase("body") || fieldName.equalsIgnoreCase("environment") )
        {
            parser.setDefaultOperator(QueryParser.AND_OPERATOR);
        }

So we limited the AND operand as the default to only the following fields:

1. Summary
2. Description
3. Environment
4. Comments

Any other text fields will still be using the default operand, which is OR, and the combination between different search conditions is always AND unless you use the advanced search to change that.

We now have much more precise and useful search results. We no longer have people overloading the server with their imprecise searches. And if someone happens to enter a very generic search term, he no longer gets the message that the number of search results exceeded the configured limit, but the other not-so-generic search terms limit his search results as they well should.

We have also provided the details to Atlassian in our support ticket with them, in the hope that they will implement the change or even better make this an admin-configurable option.

Volker, you bring up a very good point. Two keywords searched with an "OR" combination typically take much longer to execute than the same two words with an "AND". Resolving this bug would actually have two really important benefits. Search performance would be vastly improved and search results would be much more accurate.

Atlassian, please up the priority on this. It is a trivial change for a huge win.

Perhaps some of that internal discussion that led to CONF-1881 being implemented could be shared with the JIRA team, so that this issue here (JRA-5930) finally gets some traction. The same arguments used there apply here too, except even more so.

Björn and Nick in CONF-1881 have said it so well - the default search behavior undermines user confidence, they get frustrated by not being able to narrow search results down in the way they're used to, and they give up searching.

We now use a Google search appliance that indexes our Confluence and JIRA instances (among other things), and searching that is far more popular than searching in JIRA directly, although it doesn't give you access to all those other JIRA search features, and its results are arguably less useful than JIRA's. But it's the fact that they can search in it the way they're used to that makes or breaks the deal for the users!