The issue is still happening in one case I tested.

For example:

text~\"Search_Item\"

-It doesn't happen when doing the search inside Jira (by selecting jql search instead of basic)

I type in the search box: text~\"Search_Item\"

and it works as intended.

-It doesn't happen when using the Rest API, and having it as Url arguments, for example:

https://Jira.net/rest/api/3/search/?jql=text~\"Search_Item\"

GET http method

works as intended.

It however happens when doing a POST method, maybe something with my setup, or might be a bug in Jira

but I do get the issue when using POST.

For example:

The issue happens.

This ticket should not have been closed.  The exact match method that was fixed in 6.2.3 does still not cater for the main subject of this ticket, which is that the underscore character is still considered as a space in the searching in JIRA.

Yes, as search such as:

summary ~ "\"full screen\"" will return only issues that match that exact text, no stemming will be done and stopwords will not be removed.

is true, but a search for:

summary ~ "\"full_screen\"" will find summaries that don't contain the underscore.

Therefore, still not solved.

Hi cameron.fowler,

The improvements described in my [https://jira.atlassian.com/browse/JRA-14641?focusedCommentId=716064&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-716064|comment above] have been delivered in JIRA 6.2.3 and above. Hence, the fix version on this issue of "6.2.3".

Hope that helps

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

Hi all,

We believe that after the changes done at JRA-9240, this use is catered for by using the exact text search syntax:

Now, performing a JQL search such as:

summary ~ "\"full screen\"" will return only issues that match that exact text, no stemming will be done and stopwords will not be removed.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

This search bug is causing problems with our searches. Many issues reference database field and table names that use underscores... so a search for the precise underscore-containing-string tends to return about twenty issues instead of just one or two. Very annoying.

The error that I am receiving from searching with an underscore is actually a little bit different.
So searching for issues with IT_DR in their summary.
summary ~ IT_DR ..... this yields results with SAT_DR along with our other results. (simple solution was to say !~ SAT_DR) (try1)
So I poked around for a bit.
Seached:
summary ~ IT_ .... this yields no results at all? (try2)
summary ~ "\"IT_DR\"" .... same results as (try1). (try3)
summary ~ "\"_DR\"" ....... same results as (try1). (try4)

summary ~ "\"T_DR\"" ..... same results as (try2). (try5)
summary ~ "\"_\"" ............ same results as (try2). This one was weird to me* (try6)

At any rate, if this could be fixed that would be great.
In the mean time we will use more complex filters to eliminate unwanted results.

Also linked to https://jira.atlassian.com/browse/JRA-33151 and disappointing this is still not fixed

There appears to be a bug with Atlassian JIRA concerning their rather poor search functionality - If we can employ holistic searches on our internal Apps it is quite disappointing that a professional software house like Atlassian cannot do something similar.. we do not always know the VEPARSER number .. someone else seems to have reported the bug https://jira.atlassian.com/browse/JRA-33151 s

See below:

We are searching for pr_rel_ items (in this case we are looking for VEPARSER-410) if we search the field “SUMMARY” and add pr_ it returns VEPARSER -410 but if we try to narrow down with pr_rel or pr_rel_12M JIRA does not return all items -not at all helpful!!

Although we've made some other search improvements recently, this issue is not on our short term backlog. It seems simple on the surface but is actually a very large amount of work.

Please continue to vote if you'd like to see the priority raised.

When will this bug be resolved?

No reason. I erroneously resolved it as a duplicate then reopened it and it went back to open instead of verified. I'll move it to verified again now.

This was Verified status before. Is there a reason it was moved back to Open?

Is there an emoticon for an underscored ass?

Underscore MY ASS, how many years should it take before this simple bug is fixed.
I'll be back in 2015.

This is major problem in the company I work for.

This bug discourages people from making use of the wiki at all.

Very disappointing behaviour, indeed.
Even more disappointing is for how long all these related tickets have been open.

Additionally there is no escape character \_ to override underscores being treated as spaces.

I believe Lucene uses the underscore for separating words. So that searching for abc, will find abc_def, which is the desired behaviour.

Currently there is no way to enter a search string such that it requires the presence of an underscore. The overall issue for allowing to make more exact matches is JRA-5567, please vote for it.

Cheers,
Anton