I have several issues with the phrase "KidVantage" in the description. Performing a search on "KidVantage" or ""Kidvantage" finds 9 issues. However, searching on "k*vantage" find no issues. Likewise, "kid*vantage" finds no issues.
      Again, "ki?vantage" finds no matches. The help on query syntax says "*" can be used as a wildcard if not in the start position:
      "You can also use the wildcard searches in the middle of a term. For example, to search for Win95 or Windows95 you can use the search "wi*95"."
      It would seem wildcards aren't working.

        1. screenshot-1.jpg
          screenshot-1.jpg
          75 kB
        2. screenshot-2.jpg
          screenshot-2.jpg
          36 kB

          Form Name

            [JRASERVER-6187] wildcard search fails to find matches

            Chris.DeLacy added a comment - - edited

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

            Chris.DeLacy added a comment - - edited Fix this please.  This is a base expectation of any issue tracking tool.

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

            Igor Rodrigues added a comment - 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

            Eric Dalgliesh added a comment - 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

            IK added a comment - - edited

            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...

            IK added a comment - - edited 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"

            Gajan Umapathy added a comment - 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"

            David Yu added a comment -

            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.

            David Yu added a comment - 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.

            Marc Gribbons added a comment - - edited

            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?

            Marc Gribbons added a comment - - edited 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.

            DI Christoph Enzinger added a comment - 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.

            Roy Foss Motors added a comment - 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.

            Neal Applebaum added a comment - 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.

              edalgliesh Eric Dalgliesh
              6e88f3fc96e7 Neal Applebaum
              Affected customers:
              35 This affects my team
              Watchers:
              26 Start watching this issue

                Created:
                Updated:
                Resolved: