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

Bug #5943 reported by Dafydd Harries on 2005-12-19
78
This bug affects 8 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

I know I saw a bug recently with "410" somewhere in the comments, talking the HTTP 410 Gone response code. However, if I try and search for bugs containing "410", Launchpad just takes me to bug #410.

1. Go to <https://bugs.launchpad.net/ubuntu>.
2. Search for "410".

What happens: You end up at a bug report that isn't even about Ubuntu.
What should happen: You get search results for "410", e.g. bugs about handling of HTTP 410 Gone responses.

See also bug 271711, "Not obvious that you can search by bug number".

Brad Bollenbach (bradb) wrote :

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?

Dafydd Harries (daf) wrote :

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.

Changed in malone:
status: Unconfirmed → Rejected
Matthew Paul Thomas (mpt) wrote :

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

Changed in malone:
status: Rejected → Confirmed

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.

Christian Reis (kiko) wrote :

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

Christian Reis (kiko) wrote :

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?

description: updated
summary: - can't search for numbers in Malone
+ Can't search for numbers

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

era (era) wrote :

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?

Martin Pool (mbp) wrote :

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.

description: updated
Chris Halse Rogers (raof) wrote :

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.

era (era) wrote :

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

summary: - Can't search for numbers
+ Can't search for just a number in bug search: the jump-to-bug feature
+ takes over
Changed in launchpad:
importance: Medium → Low

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.

William Grant (wgrant) on 2015-09-11
tags: added: bug-search
Natalia Bidart (nataliabidart) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints