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"

My findings match Marc's test results in JIRA 4.2.4. Wildcard searching seems to just break depending on where you place the wildcard.

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.