Can't search for just a number in bug search: the jump-to-bug feature takes over

I think that this is a feature. 99% of the time that you enter a number, you mean to jump to the bug ID. Otherwise, you can provide additional criteria, e.g., "HTTP 410" will find this bug report.

What do you think?

Hmm, I agree: most of the time you want to go to that bug. I'm not sure how to improve what we've got, short of making Malone read my mind, so let's close this for now.

Still a problem -- and the "HTTP" suggestion won't work, because (for example) few bugs about 404 pages will use the word HTTP.

This is specified in <https://wiki.launchpad.canonical.com/MaloneSearch#head-d6916109d6da5e8aac4c3cafc343697f79787d47>.

Also, chipset search fails. When looking bugs related to Intel 82801G and you enter:

82801G

Search displays 0 results though the word is used in bug summaries.

Mikko, that's a separate bug -- I think it happens because of the way our full-text indexing works.

One solution would be to present a listing of bugs matching that number with the bug with that ID presented first in the list, or perhaps separately before the list. What do you think of that solution?

> One solution would be to present a listing of bugs matching that number with the bug with that ID presented first in the list, or perhaps separately before the list. What do you think of that solution?

That sounds reasonable to me.

In fact that is pretty much what the top-right search box does now eg <https://edge.launchpad.net/+search?field.text=410>

However, when you do a search from https://bugs.edge.launchpad.net/bzr/+bugs it does not work, it just takes you direct to bug 410 - even though bug 410 is not even in bzr and in this context it's highly likely that I am wanting to search for a bzr bug.

It's kind of similar to bug 785458 that you can't search for phrases either.

There is only one search box now and it brings up good results for "410" and even "8210G" (although it thinks bug #8210 and question #8210 are "exact matches", but then you get actual exact matches in "other matches").

Could this bug report be considered fixed?

No, the exact original reproduction still fails: go to https://bugs.edge.launchpad.net/malone and enter "410". And that page does still have two search boxes.

This is particularly annoying for X, where we shove the chipset in the bug title - which is almost uniformly a number. Searching for “945” is something that we'd really like to be able to do, and it's frustrating when using the search from the xserver-xorg-video-intel bug page this takes us to bug 945 which isn't even in xserver-xorg-video-intel.

In duplicate bug #624532 I try to argue that at least Advanced search should perform a regular search. It seemed to me like a compromise of sorts; maybe keep the "jump straight to bug #" semantics in Simple search but make it possible to search for a number via Advanced search. (In fact I was surprised that this bug also infests Advanced search.)

So, I appreciate that this annoying. There are several things needed to fix it.

Firstly, we need to verify that we preserve strings of numerals in the
full text search index.

If they are not indexed, we need to change the code so they are, and
reindex the DB.

Once they are indexed then it should be fairly easy to change the
search to not shortcut on a number, and just list the exact bug first
in the results; I think this would make a lot of sense and still be
useful for folk.

We could look at a foo:xx thing to control this, but I don't think its needed.

From comment #7:
> It's kind of similar to bug 785458 that you can't search
> for phrases either.

(To save others the trouble of tracking this down: the bug in question is actually bug 78458.)

I'm still having this issue. I was trying to search 24 (because of a 24-hour format issue), and I ended in bug 24.

This also affected me today. I wanted to search for a "504" as in the http response code, which I know we had a bug filed for a page returning that, and I was redirected to https://bugs.launchpad.net/baz/+bug/504 with a 404 because I can't access the "baz" project, which was very confusing and unexpected.

To me, when searching in a project bug list for any search term I expect to not be taken out of the project context, so even if a "number" search text takes you the bug, it should at list filter by the bugs in that project and have an explicit error if the bug number is not to be found in that project.