If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

quicksearch should support "#1234" as a quick redirect

RESOLVED WONTFIX

Status

()

Bugzilla
Query/Bug List
--
enhancement
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: Mike Frysinger, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
Created attachment 8611067 [details] [diff] [review]
quicksearch-one-hash.patch

often times people refer to bugs in changelogs by the format "#1234" rather than verbosely saying "bug 1234".  when you copy & paste that into bugzilla, often times it includes the # which ends up doing a literal search for "#1234".  since "1234" already bounces directly to the bug, i think letting quicksearch omit the leading # is acceptable.  in the off chance you actually want to search for "#1234", you can always do a direct search (much like you can today for "1234" or bug aliases).

open (mostly  pathological) questions:
- support inlining comments ?  #1234#5 would go to bug 1234 comment 5 directly
- support the extended whitespace/comma normalization or not worth the effort ?  today " 1234,, " will go to bug 1234.
- support multiple bugs ?  "#1234,#5678,666"
- support stripping of trailing comments w/multiple bugs ?  "#1234#5,#5678" would be turned into "1234,5678".
- support normalization of chars ?  should "  #  1234 ,,," go to "1234" ?

imo simply supporting a literal "#1234" is a good trade off as the current comma/space normalization is based on regexes rather than token splitting.  but it feels a bit weird to support "#1234" and "1234,5678" but not "#1234,#5678" ...
Attachment #8611067 - Flags: review?(glob)

Comment 1

2 years ago
#foo is already used as a shortcut for "summary or comments".
(Reporter)

Comment 2

2 years ago
ok, that probably covers the extended questions.  imo, #1234 should still redirect to the bug 1234 rather than performing a comment search for "1234".  the former is way more common than the latter.
# is an established shortcut and overloading its meaning would mean it's no longer possible to search for a number that happens to be a bug number (eg. when searching for an error code that happens to be a valid bug number).
eg. "#1168739" performs a search instead of opening that bug.
and as you pointed out if we're to support this it needs to be done everywhere.

due to the conflict with the existing # i'm not going to accept this change.

however i can see how it would be useful for your company that use the #1234 convention.

what i suggest instead is you file a new bug to add a hook to Bugzilla::Search::QuickSearch that allows extensions to add quicksearch shortcuts.  that will allow your site to develop an extension that provides this feature in a way that is supported by bugzilla (you'd also want to linkify in comments via the bug_format_comment hook).
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
Attachment #8611067 - Flags: review?(glob)
(Reporter)

Comment 4

2 years ago
(In reply to Byron Jones ‹:glob› from comment #3)

to clarify, this isn't a random company trying to push internal conventions.  this is common parlance in the open source world.  github (arguably one of the largest open source project holders at this point) supports this convention, as has historically projects like Sourceforge (and its downstream derivatives and fork).
You need to log in before you can comment on or make changes to this bug.