The sign '#' in front of bug number prevents the search function to work as expected, '#' is commonly used in gentoo docs/forum to mark a bug. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The bug isn't actually called #83781, it's 83781. People refer to it as Bug# 87381 , it's like saying Bug Number 87381.
-
You are right, but ... In every Changelog and similar docs you can read ' ... to bug #nnn ...'. Now clicking with the mouse button onto #nnn and pasting this with middle button into the text field yields in pasting #nnn instad of nnn as the bug number of interest. It is only a minor thing which makes life easier if the search function would action the sign '#' too. So, that's why I would like to reopen this bug.
this should be fixed as now bug links work as expected in bugzilla. there is no need to copy/paste it. -jeffrey
re-appeared again - checked it few minutes ago
Re-opening on OP request.
*** Bug 447322 has been marked as a duplicate of this bug. ***
Created attachment 404058 [details, diff] quicksearch-one-hash.patch
Created attachment 404060 [details, diff] quicksearch-many-hash.patch
first some background: the quick search field has three main modes of operation: (1) single bug number -> you get redirected to the report (2) list of bug numbers (split by commas or whitespace) -> you get a listing of just those bugs (3) a search string -- whatever you type in becomes the query things to note about (1) & (2): all whitespace & commas are normalized. e.g.: " 1234 ,, ,, , " -> "1234" -> redirected to report 1234 " 1234,,,,5678 ," -> "1234,5678" -> shown a list w/just those two bugs we could easily support a single bug with a single leading # ... see quicksearch-one-hash.patch for how but thinking pathologically, do we want to support more ? how about multiple items like " #1234, ,#5678, " ? quicksearch-many-hash.patch handles that. should i be able to paste in something like "#1234#5" (bug 1234 comment 5) ? or should bugzilla do a quicksearch for that ? but what about " #1234, #5678#22" ? and what if you want to search for a real string like "#12#45#67#" (think low level data streams) ? i'd lean towards Gentoo adopting quicksearch-one-hash.patch as it lacks any sort of ambiguity, and move any further discussion upstream. that's a pretty good trade-off i think in terms of mitigating our pain.
Created attachment 404062 [details, diff] 0001-quicksearch-support-1234-bugs.patch
Comment on attachment 404058 [details, diff] quicksearch-one-hash.patch use the more formal 0001-quicksearch-support-1234-bugs.patch
thx.
this is live in our install now: https://gitweb.gentoo.org/proj/gentoo-bugzilla.git/commit/?id=2f3202ed9560b700625912c6702472949ec91ae1 upstream has declined to take the change despite my requests ;).
