From a user perspective, I just got a report touching this issue: "When I add a wildcard, I sometimes get less results instead of equal/more results"

Why was this changed from a Bug to a Suggestion?  It is most clearly incorrect and inconsistent behavior.

We're seeing the following behaviour with Jira 9.12.10.

String PLM-UI-01

• ~ "PLM-UI-01" works
• ~ "PLM-UI-*" does not work
• ~ "PLM-*" does not work
• ~ "UI" works
• ~ "UI*" works
• ~ "UI" does not work

String PLM-UI2-01

• ~ "PLM-UI2-01" works
• ~ "PLM-UI2-*" works
• ~ "PLM-*" works

If there is a number in the chunk after the first hyphen, a wildcard search matches it, if it's text only, it doesn't.

Prefixing a word with a wildcard does not work for us in Jira Cloud.

Why isn't this implemented? By not implementing this, it is in fact not a "contains" operation, but a "prefixed by". Can we get a comment from Atlassian on whether this will be implemented?

The question was asked:
"I have long since realized that it won't be fixed, but an interesting question is: Is the same query well behaved on the Cloud version?"

I experience the issue on the cloud version.

Or even more interesting for those who cannot go with Cloud (like us). What's about Datacenter?

Apart from that i cannot imagine, that there is big difference in the code base between Server, Datacenter and Cloud versions.
The insufficient profit situation for the Server version, as mentioned by Sean M, most likely results from the necessity to support several platforms, i guess. But i agree that this is what Atlassian want's to get rid off.

I have long since realized that it won't be fixed, but an interesting question is: Is the same query well behaved on the Cloud version?

Clearly the Server product isn't sufficiently profitable to support, as evidenced by Atlassian's recent decision to kill it off. So Server tickets like this just seem like a waste of time, and 8+ year old tickets that never got solved will just be a part of Atlassian's legacy. I wonder if they'll keep them around.

The ~ search is simply not working as described. And there's absolutely no chance to get the desired results.
Please see https://getsupport.atlassian.com/servicedesk/customer/portal/20/GHS-202723
We are wondering that this ticket is now open for nearly 8 years.

+1

Somewhat. There are still issues. Most notably I have found dashes really mess with the search. For instance I have a ticket who's summary is "MGMT-ANLYST-01". JQL like this ...

text~"*-ANLYST-*"

... returns nothing. However this ...

text~"MGMT-ANLYST-01"

... does return the issue.

Just found this, which seems relevant: https://jira.atlassian.com/browse/JRASERVER-6218 It is implemented in 8.6

We have problem with this issue in our company, too. All issues in a specific project have prefix and "/" as a delimiter, e.g. "Prefix/Word to be found". We are unable to search for it via summary ~ "word to be found" The problem is that "/" does not define word boundary. For this case, it should be enough to add "/" to word boundary list in Lucene.

+1

Since you're upgrading Lucene to 7.x in Jira 8.0, can you address this issue as part of that upgrade?

Guys, it's awful.

Hard to believe that something that has a direct analog in virtually every programming language on the face of the Earth can't be properly implemented...

It also concerns Version 7.2.4 !

Sill encountering this problem in JIRA v1000.1065.1 

If I search for:

summary ~ Test

If the summary contains:

ExchangePowerShellTest

... Then there is no match.

It matches if the text is at the beginning of the word, but not if the text is at the end of the word.

Please!!!!

Really wish this would get fixed ... it is hard to realize what is happening when your search isn't working when all other searches using the same method work. Also, the "workaround" to use "issueFunction in issueFieldMatch(...)" is not intuitive and wouldn't even cross the mind of an average user.

Please fix!!

Alan, if this issue is of particular concern to you / your company, you would be best to move away from using JIRA as your bug tracker, because Atlassian clearly have no interest in fixing this issue any time in the next 5 years.

JIRA 7.2.7 still has this problem.

Please see extra information in the related (but closed) issue: https://jira.atlassian.com/browse/JRA-32985

There seems to be a problem when searching with a hyphen or underscore AND there is a word that contains a number character.

For example:

summary ~ "FT-" 

Will find the following summary

FT-ABC

But not this one

FT-ABC1

Since there's been no movement, or any hint of movement on this issue in 3 years, I think you'd be best to get on with migrating to another product and cut your losses with Jira, before it 'infects' the rest of your company and becomes too expensive to move away from.

This is major issue within our company.. Please fix it asap. Otherwise we will discontinue using this product.

Jose, your "workaround" actually does also not work with a leading wildcard.

What actually works for a summary "Find JRA_SEARCH in a summary" when not knowing the "JRA" Prefix:
[noformat]
issueFunction in issueFieldMatch("project=JRA","summary", "
b*SEARCH")
[noformat]

So, also the Script runner needs first to be convinced to accept the whitespace as a "first" character by pushing in a "word boundary" marker.

This is less than intuitive - and also not documented.

Please fix Jira. It cannot be so difficult.

To our users, this is a real problem because they are looking for summary~*consistent and want to find all issues which carry "consistent" or "inconsistent" in their summary.
Is there a technical reason that this should not work?

Not allowing a wildcard as the first character is a huge problem when it comes to searching variable names in summaries which are prefixed, but you don't know the prefix. JIRA should not hide these matches.
The expected default should be to match either any substring matching the string provided with ~ (but then you might want to extend to a regexp word boundary such as \b) or to provide any means indicate that the user performing the search does not want to match word boundaries (i.e. allowing a wildcard).

Please seriously consider to fix this problem.

The crux of the leading wildcard issue is the first character can't be a wildcard. The limitation lies in that you would at least need the starting character of the string. So HX4000 for instance. Something like summary ~ "H?4000" or summary ~ "H???00 where ? works a wildcard for a single character could work. In the case you only know a few letters someone like summary ~ "H*0*" could work as you can double wild card with * in-between characters. You can even use a combination such as "H?4*" as well.

If you are like me though. You want a little more power and would like to get beyond this limitation in JQL and search for the tail end of HX4000 for instance. I would highly recommend Script Runner a third party add on. I know what you are thinking oh no not an add on! However it's free. Script Runner really beefs up JQL as you can use regex with script runner.

 For example: issueFunction in issueFieldMatch("project = JRA", "description", "ABC\\d{4}").  

See more on IssueFieldMatch here.

I did update our Performing Text Searches as I agree we need to raise awareness and close the loop. I also realize the syntax for regex might be a bit much for the average user as well as cumbersome for a basic wildcard search. That being said while we look to improve Jira's search engine to make it more robust. I wanted to make folks aware of this option.

Thanks,
Ramiro Castro
Support Engineer
Atlassian

What does it take to get this assigned for a fix? This is a major problem for my team and our use of your products.

JRA-32985 IS NOT RESOLVED, as acknowledged by your team in JSP-230040!

Please fix these problems so that your systems behave as your documentation and feature-set promises. Failure to do so expediently will result in a desire for my team and my employer to seek other products that work as promised.

I think my issue is related to this one. We have lots of issues that have their summary prefixed with certain values. For instance, if I want to find issues prefixed with "WR-" I do a search "summary ~ 'WR-'", but I will get results for anything that contains "WR" when I would expect to only get values back the contain exactly "WR-".

Basically, it seems like the dash is being completely ignored in the search. I get the same results back for "summary ~ WR" and "summary ~ WR-"

This is a pretty major issue for us, as it makes it nearly impossible to narrow down our search results to something meaningful.

Already asked the servicedesk and they directed me to this ticket.

See my request, seems to be related:

Hi,
I have several "Story" type tasks with a title like "some description (XYz bla)". These tasks have an epic link to an "Epic" type task with the title like "XYz blub". I think that the "XYz" is the important part.
When I search for the string "XYz" in the search field, Jira finds the Epic (containing all these other Story tasks) but does not show these specific task as part of the result.
If one of these Story tasks is unlinked from the Epic, the Story is part of the search result.

JIRA version: 6.3.12

search:
text ~ XYz

We are facing the same issue with <space><hyphen> e.g. A query like "Field" ~ "XYZ - ABCDE FGH" gives out the result XYZ even though the system has lots of XYZ - ABCDE FGH values.

Issues with a backslash \ in the summary don't show up in any search at all. For instance with summary equal to "TFS\Project Name" if you search for "TFS" no results are found.

Perhaps JIRA should not allow import of issues with \ in the summary if the search won't work...

I have this case to add to the pile of unexpected results:
Issue 1 description contains: 544-Validation-Panasonic
Issue 2 description contains: 544-Validation-IPv6

Case 1: Description ~ "544-Validation-" returns issue 1 only
Case 2: Description ~ "544-Validation-*" returns issue 2 only
Case 3: Description ~ "544-Validation" returns issue 1 only
Case 4: Description ~ "544-Validation*" returns issue 1 and 2
Case 5: Description ~ "544-Validation-Pan*" returns nothing
Case 6: Description ~ "544-Validation-IP*" returns issue 2

It seems handling of - is inconsistent, but the handling between case 5 and 6 makes no sense.

Simple test like the following:
Issue 1 summary: "IT Testing"
Issue 2 summary: "UK Testing"

Searching for summary ~ "IT" yields no results, while searching for summary ~ "UK" yields issue 2. They're both english letters but why the search inconsistency ?

Is this a minor improvement, or a critical bug...?

We have a gadget that provides a number of tickets based on a query and a url. When clicking the url the number of tickets produced is different from the number showed by the gadget. This is clearly jira reporting tickets that doesn't correspond to a query, a big hole in a defect tracking system.

I have another example using a custom text field that contains a key (representing a value from another app):
The key is of the form "U-SUBS-23".
I want to be able to search for all the user stories that have a key with a value beginning with "U-SUBS-".

This query gives an error that the hyphen isn't escaped:
"Contour ID" ~ "U-SUBS

This query returns no results ("<backslash>" is a real backslash but it doesn't display in this ticket):
"Contour ID" ~ "U<backslash><backslash>-SUBS"

This query returns too many results ("<backslash>" is a real backslash but it doesn't display in this ticket):
"U<backslash><backslash>-"

It's very frustrating that it's so inconsistent. I added this field specifically to allow users to search by this key

-Alasdair

First, I want to say that this search box defies reasonable user expectations: Convention has been set with so many other systems where search boxes do substring matching. You can't place a similar search box in a similar place, and yet expect the customer to understand the extensive limitations of your search.

At the very least, you need to revise the search results to include details about what kinds of searches are valid and expected to work, especially when few or no results are found.

Second, I don't think the problems are this linear. The partial matching is not consistent at all:

I am searching for an issue with the summary of "zsc-pbt1-sd.abc RAID". If I search for "project = OPS AND summary ~ pbt" I get no issues. It is invisible to search, even though the search should match. This is utterly essential. Having an issue repository in which we cannot find issues without guessing the mindset of the issue creator is USELESS.

More to the point, the node type is the prefix and the site is the second part. I need a valid way to find all issues for the site.

But it gets more interesting: Then I search for "project = OPS AND summary ~ zsc" I get three issues, none of which are this one. They are "zsc-ptelegen1.abc", "zsc-gigalot2.def", and "zsc-paris2a.ghi"

Why exactly does "~ zsc" match all of these nodes, but not "zsc-pbt1" ?

Hey Matt,

I just want to be clear that the comment about Lucene is NOT something which anyone in Atlassian has verified to date. This is simply a statement a customer made which I felt should be passed along in this issue for further review.

Cheers,
Boris

If it is a limitation in Lucene, it would be very useful to have it clearly documented for JIRA users who want to search

A customer reported that Apache SOLR seems to have the same issue. So this may be a limitation in Lucene itself and not an issue with JIRA implementation.

Agreed, the expected and actual behaviour is a mystery to most at the moment. I'd like to see a clear description about how JIRA searching works.

1. There's a Lucene document for each JIRA issue. You can use the tool such as Luke to look at what is stored there
2. When a JIRA issue is indexed, the value for the summary is tokenized in some standard Lucene way (what is that way?) and added to the Lucene document
3. When a JQL query is parsed, it produces a Lucene query. What kind of document matches are expected for the Lucene queries that are used?
4. The ids of the issues that match the JQL query are returned to the Issue Navigator for display as search results.

Then the JIRA admins could explain it to their users, or refer them to the Atlassian documentation.

And is what is done for the summary field the same as what is done for other text and other custom text fields?