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

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

            Melissa added a comment -

            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?

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

            Dylan Etkin [Atlassian] added a comment - 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.

            Luis Sigal added a comment -

            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!

            Luis Sigal added a comment - 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!

            BrianH added a comment -

            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

            BrianH added a comment - 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

            Luis Sigal added a comment -

            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

            Luis Sigal added a comment - 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

            Scott Farquhar added a comment - 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.

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

            Nick Menere [Atlassian] (Inactive) added a comment - 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 Applebaum added a comment - 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.

            Jeff Turner added a comment - 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 Applebaum added a comment - Any chance the third party search tool will resolve this problem in 3.2? Thanks

            MarkC added a comment -

            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

            MarkC added a comment - 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

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

                Created:
                Updated:
                Resolved: