Jira searches all Text-Fields. Number fields are not searchable via quicksearch. see also: https://confluence.atlassian.com/jiracoreserver073/quick-searching-861257204.html

 BTW: this is an 16 year old issue which was resolved in 2012 (Jira Version 5.2)

I am unable to search custom fields using the Search bar. 

and Advanced search returns results but this defeats the object of having a quick "Search" function. 

I have a Jira server Jira v8.10.0 and I can't search custom fields using the quick search in the board's top right search bar. Am I missing something?

Hello.
I am a novice administrator.
I have a question that archs with the decision how and where should I insert it so that everything would work for me? thanks for the answer.

Thanks Roy, Nick and the rest of the team who worked on this! I will have some happy campers here.

Cheers

Hi guys,
As of 5.2 JIRA will search across all text based fields when querying from Quick Search and from Simple Search.

Cheers,
Nick Menere
Lead JIRA Product Engineer

additionally, we should also be able to search by number, by specific dates (like in JQL). Quick search shouldnt be limited to just ticket number (with PKEY), title and comments.

guillaume_c, thanks for the feedback.

No I was initially referring to the ability to swap between advanced and simple searching, however that is now no longer in scope and I have updated my feedback comment accordingly.

The proposed solution look good.

When you say "at least for the first implementation of this" does that mean that in a second implementation people will be able to search for text in any field in the simple search, so the quick will be able to return in simple search? Because that would be great.

Proposed solution sounds good.

I am with Mikael: I just want it to work. Like John we are also double-entering text into descriptions to allow for searching.

I am not in a position to validate if the solution proposed is the best one. If it works it sounds good to me.

The "text ~ foo" solution is fine for us. My original comments are way up at the top by now, but the main use case for us is that we have a custom ID field "Tower Id" with values like "NC2000". If a user fills it in and then does a quick search, it won't find the issue and they either file a bug report with me or they assume there's no ticket and create a new one. The workaround has been to also put the id in every ticket summary (like "NC2000 Test Ticket") but that is not ideal. If someone forgets to do it, we have the same problem where they assume no ticket exists, since people usually put the id in the summary.

From my perspective, the quick search box should be straight JQL. Anyone who has spent more than a day working with JIRA knows what s/he wants to search for. The Smart Query short hands are band-aids that'll hurt JIRA in the long run. It is probably worthwhile to consider making the Quick Search box a straight JQL box from the user Profile. That'll shut me up and avoid annoying the people who like the Quick Search box just the way it is.

I just want it to work, the solution behind i personaly don't care about.

I also think that the proposed changes would be a good solution.

The proposed solution would be a good step for starters Roy Krishna.

Cheers,
Joe

Unfortunately not mikaelhagberg.

However I'd love to get some feedback from all users watching this issue for our proposed solution I mentioned earlier:

Will this be fixed in v5.0?

We also want to get this fixed, however we have limited resources at this time.

Our plan is to change the quick search behaviour to be the equivalent of text ~ foo in JQL and the results will be in Advanced view (JQL) only (at least for the first implementation of this). Please note that this means that quick search will search the environment field.

Any feedback to this proposed solution would be welcomed.

Cheers,
Roy

I'm really curious why it's taking so long to solve this issue. So many comments, so urgent calls to solve it, dozens of votes. Even one patch from community member. Hey, Atlassian, do you really need more feedback to do it?

Would be GREAT!

The issue with using JQL is that if you want your search to include the issuekey field, it throws an error if it does not find the issue key. Is there a way around this?

Thanks for the idea goran.

In my case, I only needed a way to search quickly for one custom field, so implemented it through a Bookmarklet.

The following javascript will search a custom field called "Story points" in all projects, but you can easily transform it to your needs, thanks to the search permalink in JIRA.

javascript:d=document;t=getSelection()+'';if(!t)%7Bvoid(t=prompt('Enter%20story%20points...',''))%7D;if(t)%20location.href='https://www.YOURJIRA.com/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=%22Story+Point%22+%3D+%22'+encodeURIComponent(t)+'%22';

Cheers

Here's one idea:
Add a text gadget with the HTML containing at least one input box and one button/link. Add javascript to build the correct JQL-based URL which would search for appearance of the search term from the input box in all the fields of interest for you. Then open the window using the built URL and off you go!

We need the ability to search custom fields with the quick search. We are currently JIRA and Confluence customers, I hope this can be resolved quickly, since someone else has provided you with a patch. This seems like something that should be as easy as changing a configuration file for the end user.
Thanks

hello Atlassian,

will there be done something in this case (further versions)?
I don't understand why this issue is not assigned since YEARS !
Please, please, please create a configurable Quicksearch.

Chris' suggestion is no solution for us... too incomprehensible

regarding Chetan Sarvas patch: will it work in 4.2.1 too ?

I have same problem, I need to search issue by customers id. I think that what Chris suggested in 03/Jun/10, work just fine.

Hi,

To download the source code of JIRA, please access this page: http://www.atlassian.com/software/jira/JIRASourceDownloads.jspa

To know how to build JIRA from source code, follow to this article: Building JIRA from Source

Best Regards,
Thiago Auler
Atlassian Support

i have no source code of jira , what i can patch my 4.1 installation?

Use this patch AT YOUR OWN RISK. I have tested it only against our own internal requirements and it meets our needs. Whether or not it works for you is a different story. You are welcome to modify it as I'm releasing it under the Apache 2 license.

I'm still a bit unclear on where to submit a patch so I'm posting it here for now.

please Atlassian, make this patch available for all.
This is a very serious issue in IMHO and I dont get it why it is not solved by Atlassian IN THE LAST 5 YEARS ???

@Chetan Sarva

Hi Chetan, thanks for your enthusiasm.

I wrote a patch against 4.1.2 that implements this functionality. I'm not clear on what the licensing is around the source download, so I'm not releasing it. Can someone from Atlassian clarify?

Here is an article explaining how to send a patch to Atlassian.
http://confluence.atlassian.com/display/DEV/How+to+submit+a+patch

Thanks for your contribution.

Best Regards,
Thiago Auler
Atlassian Support

PLEASEEEE
I NEED IT !!!!
send to me !!!! PLEASE !!!! My supervisor want to KILL JIRA because this issue !!!

send to dyego.carmo@go-java.com , PLEASE !!!

I wrote a patch against 4.1.2 that implements this functionality. I'm not clear on what the licensing is around the source download, so I'm not releasing it. Can someone from Atlassian clarify?

Wow... this issue has been open for 5 years now?!?!

More one...

Please Atlassian , solve this very big problem...

To make it short: This is one of the reasons why my company dumped its Jira enterprise license and turned to another solution.

I'm now on company #3 (see prior comments) where I am trying to get JIRA spread to the business teams and this is a problem for them. We have a business-related entity (Tower Id) that is a custom JIRA field, and I keep getting bug reports like "JIRA Search is broken" and have to patiently explain that the custom field can't be searched via quick search (only by using Search For Issues and awkwardly scrollllllllllllling way down past a bunch of other stuff).

What's worse for them is that I told them to always put TowerId as part of the summary as a workaround (in addition to putting it in the custom field). That seems good on the surface but it actually makes it worse, because then some user forgets and the ticket gets "lost". Example: Users dutifully place TowerId in the summary for 9 tickets. Search finds them. A 10th user creates a ticket but forgets to put towerid in the summary, although they put it in the custom field. The assignee team searches and finds 9 tickets instead of 10. They are getting enough hits that it seems to we working, but the 10th ticket ends up "lost" until someone gets around to browsing the project or analyzing their dashboards.

We would really, really like this feature.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I will be away on vacation until 10th.
For any urgent issues, please contact to Hosang Lim(hslim@inustech.com).

Thanks,
Heewook
.

I'm just thinking aloud here people, but...

...now that we have advanced search, who here would find an advanced search text box in place of quick search (a user preference) to be a workable alternative to this issue?

This lack of functionality (I'm tempted to call it a bug) is now approaching its fifth birthday, and it doesn't even have an assignee. What can we do to get it more attention? Thanks!

I totally agree that this enhancement is very important for an issue tracking system.

As a workaround, we have currently created a groovy script which adds in the Comments a 'system generated comment' having all the values taken from the customfields that we want the quick search to use.

At least this gives the functionality that the users were despaired to have until an official support is added.

I say index every value on the issue - description, comments, user names, id's, tags, labels, change history - everything - into one index field and have Quick Search search through that index field.

I'd even go further...recurse through the duplicated issue links and index all of those issues fields into this one field, too.

This would all greatly help prevention of duplicate issue filing.

We also could really use this. Our issues are also in a separate ticket system and having to go to the search page and scroll way down to the Custom Field just to enter in that ticket number is a lot of extra work.

Yes it would be awesome if this improvement can be made, we have old system from where we have migrated data and we need to do a Quick Search on the old system Id which is stored in a custom field

Any update on this? I commented on this 15 months ago when I was at my previous company. My current one is now using JIRA and it's bothering the users that their quick searches on a custom text field yield no results. Please fix this!

Must agree, we use JIRA to track assets and want to be able to search quickly by entering the asset serial number in the 'Quick Search' field. Now it requires us to go through 'Find Issues' to "load" the project first before we can then enter the asset serial number in the 'Custom Fields' section when searching for issues. Not very efficient or easy-to-use at all.

We have several very descriptive text fields that we added coming from the Bugzilla world - Expected/Actual results and separate information about QA verification. Not being able to quick-search these fields makes it much more likely for duplicate bugs to get filed, and harder to search for related bugs. I was surprised that custom fields aren't quick searchable, it's really frustrating.

This is a serious issue for me as well. I am trying to implement a calculated custom field that has a list of strings in it. Lucene's behaivor on the TextSearcher class is erratic at best. What I want is to be able to search for a single string that basically does a partial match.

If anyone has ideas on how to implement a CustomFieldSearcher that does this, I would like to hear.

This is a serious limitation for us too. We have opened up our JIRA installation to our customers. "Customer" is a custom field but of course they type in their organisation name into the quick search box to find their issues and then complain that it doesn't work. As a workaround people have started putting the customer name into all sorts of places (summary, description or comment fields), which completely defeats the point of having a custom drop-down list (i.e. we now have several different spellings of each organisation/project). Please fix this!

Searching in text-based custom fields is a more than natural thing. I am quite annoyed to see such simple things like this one (with an estimate of 4 hours!!!) to be open for that long.

Searching custom text fields via QuickSearch is a definitve must!

\Ralf

We use a very specific format for the bug description and would love to be able to break the description field into its 3 component parts. But without being able to use the built-in search functions on the new fields, the query is useless. We need the ability to add custom fields to the Text queries.

Specifically, we want a "Legacy ID" custom field that we can use as we transition of our old tracking system. We are evaluating JIRA (I used it at a previous job) and not being able to search by legacy id is being touted as a "show stopper" by some of our critics. And since no one is used to thinking in terms of jira ids yet, this argument has been fairly effective in fueling anti-JIRA sentiment.

Our critics basic argument is "if it can't support a simple, critical feature like searching by legacy id, then think of all the other problems we are likely to have. this is just the tip of the iceberg".

I showed a workaround by searching on custom fields using the issue navigator "Find Issue", but this pretty much just added fuel to the fire.

I would argue that if you do not want to index all custom fields, then at least add a specific custom field type for legacy id (one that is not read only) and allow Quick Search on that field.

We are using the API with Flex/Coldfusion to allow users to submit tickets - we collect their login name as a custom value, and it would be great if we could key off that field when retrieving tickets to allow users to view a history and see their status (Jira is used a piece of a larger support dashboard)

I have a ton of bugs from an old system and I want to search the old ticket numbers, but Smart Query thinks they are JIRA numbers and I get the "Issue Does Not Exist" error. I know I can use quotes, so that's a good workaround, but I would like Smart Query to be beefed up as above.

Maybe if you type a numeric search and it can't find a JIRA issue, it defaults to a proper field search?

This issue is over two years old. Is any progress being made on it? Thanks!

Being able to do such a search would eliminate the need for hacks like the comment in https://jira.ts.wikimedia.org/browse/WIKISENSE-9 . Implementation could be as one checkbox for "All Custom Fields" that have text equivalents, or as checkboxes for each of the (currently 2 at Wikimedia) "Custom Fields" that have text equivalents (the former scales better but the latter allows more granularity). See also my similar report at https://jira.ts.wikimedia.org/browse/TS-74 .

We have a large number of custom fields to do things like store hostname information for a problem report. It would be nice to have this lumped into the normal quick search. It would also be nice if custom fields could plug in to quick search (for example a custom field searcher that supports lookups on hostname or ip should be able to plug in to the quick search).

I'd like to see this get implemented. While its true that you can search on custom fields using the issue navigator "Find Issue". It is more convenient to use the "Quick Search" for text custom fields without having to click and scroll through the projects -> issue type -> custom fields and then enter in your query.

Tags. That is all I am saying.

We use a custom field for error stack information, and I've really missed the option to include this field in the Quick Search. At the moment, it is quite cumbersome to search for other issues with matching error stack information.

We use JIRA to manage issues relating to our course bookings system, and often have to report these issues to the software developer. They, of course, use their own issue reference system, so we have a custom field which we use to record their reference against our issues. They are not very good at quoting our JIRA reference in their communications, so we always have to go into the 'Find Issues' function and do a long-winded search on the custom field there.

If we could choose which custom fields we wanted to be searchable by the Quick Search box, we could find and update issues more easily.

We've migrated from Bugzilla and still have a lot of our notes and other internal references use the Bugzilla ID. We constantly are finding ourselves wanting to use the quick search field to look things up by Bugzilla ID, which is implemented as a custom field. I realize that there is a Bugzilla ID search portlet, but it's annoying to have to go to the dashboard and use a different search field. It would be extremely handy to have quick search handle everything.

In several JIRA installations I've used at several companies (not strictly for software development, but for issue management of various production processses), people use custom fields for specific IDs relating to issues (e.g. item numbers, page numbers, etc). We put them in custom fields in order to give the reporters (usually end-users) some structure and to make sure we get all the info we need. On the technician/developer/etc side, though, one of the most frequent operations is to search for an issue by that structured identifier, which cannot be easily done. This improvement would siginificantly increase the productivity of our technicians.

Yes, the ability to do a Free text search in any custom field would be most helpful. The one in particular that i'm thinking about is the URL field, sometimes you may just want to search for a number in the field. An example would be a salesforce link with an id number or a cruisecontrol link with a build number. I have already commented on this on the jira forum thread 9770

http://forums.atlassian.com/thread.jspa?forumID=46&threadID=9770