Fix this please.  This is a base expectation of any issue tracking tool.

Fix it, will ya? Love from Brazil. Cheers!

Thanks for bringing this to my attention idris.khesravi.

Recently we've been doing issues in categories as we can fix a higher total number when we do that (for example, we fixed a disproportionate number of LDAP bugs in 5.2.x and 6.0). Bugs in search are on the short list of things that we want to look at, but they aren't at the top of the list.

However, that doesn't help you right now. Our current thoughts about this bug is that it's caused by lucene stemming. To work around that, there are two things you can try: you can disable stemming by setting the language to Other - instructions at https://confluence.atlassian.com/display/JIRA/Performing+Text+Searches#PerformingTextSearches-Wordstemming; or you can try to work around the stemming in your search - match against "custom" instead of "customise" and against "integrat" instead of "integration". Until we've fixed the bug, that's probably your best bet.

Regards,
Eric

Sooo, is there any initiative to fix this? Or is this a (still unresolved) lucene core issue?

Hey Atlassian, this is open since 8 years and unassigned ! - Seriously: How about tackling this kind of deficits, before focussing on more UI "bling" !? (Or maybe nobody found the Issue yet...)

As long as this persists you can just scrap the whole wild card search feature...

Same for me on JIRA 4.34

today I did a new search:

cf[10021] = IFC and comment ~ "SEHExcept*"
it return 3 outputs.

But the following ones don't return anything:
cf[10021] = IFC and comment ~ "SEHExcepti*"
cf[10021] = IFC and comment ~ "SEHExceptio*"
cf[10021] = IFC and comment ~ "SEHException*"

Instead the following one returns the 3 outputs as the first query:
cf[10021] = IFC and comment ~ "SEHException"

Using JIRA 4.1.1 I created a series of cases in JIRA with the following strings located somewhere in the summary

pol:premiumAdjustment(s)
premiumAdjustments
premiumadjustment*

To be exact here is the exact text in 3 of the issue summaries

Transformation - Export - Create scom:finAmount, scom:attribute(s), pol:premiumAdjustment(s) Objects and BV Transforms (Parent is pol:policyTotalTax)

The premiumAdjustments complex type needs to be implementeted.

Quick Search on premiumadjustment* returns no hits when there really are matches

With only the query field "Summary" box checked and switching to the advanced searching I performed the following searches

summary ~ "premiumadjustment" 19 results
summary ~ "premiumadjustmen*" 0 results
summary ~ "premiumadjustme*" 0 results
summary ~ "premiumadjustm*" 0 results
summary ~ "premiumadjust*" 19 results

Repeating the same searches and capitalizing the letter "a" made no difference. Why is quick search full of so much fail?

After some tests I can say: In no case I got the expected search result.
Searching seems to be a completely untested feature in Jira. Trash.

I have a task with the keyword "sun" in both the title and the body, and the keyword "serial" in the body. It would seem rather simple to retrieve the task from the search field, however that's not the case. Note the following three searches and their success.

+sun +serial = task not found
+sun serial = task found
sun +serial = task found

Why would the search fail to find the +sun +serial when the search wasn't enclosed in double quotes? The two words are not adjacent to each other in the task so obviously a search using "sun serial" will not return the task. However, I thought the plus sign was merely a requirement. In this case, it appears to be doing something more then I expected.

Melissa,

When the co-worker only finds 1 or 2 of the results, do they use the exact same search criterion as you? And if so, can they view the issue if they put in the key directly? That would eliminate security issue.

We are having a similar problem but it does not seem to be related to wild cards. Say we have 3 issues that include the term "Multi-domain" in the summary. If I search for multi-domain I get the right results. If a co-worker does, they might get 1, 2, or all 3 results. It seems somewhat random. Could the hyphen be causing this randomness?

It would also seem that the english stemmer drops all 's' characters off the end of words. So in cases where you have non-words, such as GMS, the expected GMS is not indexed, instead it is stemmed and we index GM.

Hi Brian,
your comment worked!
Actually, I guess a good enough solution would be to alert after a search that some results might be omitted due to a misunderstanding of the syntax. I am not sure the syntax needs to be improved.

Thanks!

Hi Luis,

I have managed to reproduce this locally and it appears tha Jira treats hyphens "-" as spaces. This means that CO and PE and considered separate words. So if you search for CO PE or CO*. Your search should return the correct results.

Thanks,
Brian

I have a similar problem (JIRA version 3.3.1). We have a code at the end of an issues's comment (the code is CO-PE-75). When I search comments for CO-PE-75, it returns the results OK. However, if I search for CO-PE-* or CO-PE*, I don't get any results.
I have tried to reproduce it in our test projects, with different combinations of words and numbers, and everything is OK. I guess it will be quite hard to reproduce.
Yours

Neal,

I'm just looking into this - will follow up later.

However, just as a starting point - it appears that the indexer drops the last 'e', so that if you search for "k*vantag" it will work.

Not that is any real help to you - but I'm just noting down my finding here so that I can remember them later

Cheers,
Scott

even on non-custom fields, the search doesn't work vwey well.

Sorry Neal,
We are using the same version of Lucene (http://lucene.apache.org/java/docs/) 1.4-final for 3.2.

Nick

From what I understand, my bug is because the third part search tool (by Lucene) is not providing the results you are expecting, so I was hoping that maybe a newer fixed version of that tool might be included in 3.2, since I saw other issues mention that you will be using Lucene for better, faster searching.

Neal,

Not sure which tool you mean? But in any case, it won't be fixed in 3.2 unfortunately.

Any chance the third party search tool will resolve this problem in 3.2?

Thanks

Neal,

The wild card search does seem to be quite tempramental. It seems that wilcards for words with numbers seems to work nicely. Search for "win*95" in the test project.

I think the root of the problem is how lucene "stems" words, so wild card searches don't work as easily as expected.

Thanks for the report, we'll certainly look into this.

Cheers

Mark C