2018260 - "Fields You Can Search On" is blocking people from making it through quicksearch.html doc

Status: REOPENED

(bugzilla.mozilla.org :: Documentation, enhancement, P3)

Description

[Steve Fink [:sfink] [:s:]]

https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html has a list of all possible fields that is so long, that my guess is that many people assume it's the end of useful content on the page and stop reading. It would be better if it were hidden behind an accordion, or even better: separate out the fields more likely to be useful and hide the rest behind an accordion. (In particular, all the status-* and tracking-* fields make the list unmanageable.)

Comment 1

[David Lawrence [:dkl]]

I agree. A couple of solutions is to make the fields two column with the tracking flags having their own column. Also not all tracking flags are enabled and active so they could possibly just be omitted but some people might want to know about those. Another option would be to make the tracking flag list collapsed by default and only display if the user wants to see them. Something to think about.

Comment 2

[Kohei Yoshino [:kohei]]

I’m volunteering to implement this.

Comment 3

[BMO Github Automation]

Attachment: [mozilla-bteam/bmo] Bug 2018260 - "Fields You Can Search On" is blocking people from making it through quicksearch.html doc (#2564)

Comment 4

[BMO Github Automation]

Authored by https://github.com/kyoshino
https://github.com/mozilla-bteam/bmo/commit/e08f36347121563a8ff264e462c60326370bfa04
[master] Bug 2018260 - "Fields You Can Search On" is blocking people from making it through quicksearch.html doc

Comment 5

[BMO Github Automation]

Authored by https://github.com/dklawren
https://github.com/mozilla-bteam/bmo/commit/61fb48e824a9f7f997da1dd4293d034c63620322
[master] Revert "Bug 2018260 - "Fields You Can Search On" is blocking people from making it through quicksearch.html doc"

Comment 6

[David Lawrence [:dkl]]

Reopening as this had an affect on quick searches not working any more that used to work before the deployment. I reverted while I investigate why this would happen.

Also on another note, and could have been addressed in a new bug if not for the revert, I think we need to move the code that skips inactive tracking flags to template itself and not in quicksearch_map(). Reason is that people should still be able search on inactive tracking flags fields if they want to see older bugs that still have the flags set on them. But we can still hide showing them in the quick search docs maybe. Or should we render the inactive ones but hide them by default. Maybe the user will want to see bugs with the old flags set but they do not remember the exact name. Thoughts?

Comment 7

[Kohei Yoshino [:kohei]]

Ugh. We could add a checkbox to toggle inactive flags on the list. I’ll give another try...

Comment 8

[David Lawrence [:dkl]]

(In reply to Kohei Yoshino [:kohei] from comment #7)

Ugh. We could add a checkbox to toggle inactive flags on the list. I’ll give another try...

Thanks. I think if we just leave quicksearch_map() as it was before and only work in the template it shouldn't affect anything else. quicksearch_map() is used by Bugzilla/Search/QuickSearch.pm and is called by BMO extension and maybe others.

Comment 9

[Steve Fink [:sfink] [:s:]]

Attachment: (part 1/2) Separate custom fields in quicksearch help into a separate pair of columns

Back when I filed this, I played around with another approach to this that I'll include here for reference. It took me longer thank I'd like to admit and got more complicated than is probably a good idea, but I'll attach it for reference. It splits out custom fields from builtin fields and displays them in two columns, then additionally chops off the part of the custom field column if it extends below the builtin column (with a <detail> for expanding and seeing the rest). Making it scrollable would probably have been much simpler, but I don't know front-end development very well and this turned into a bit of a learning project for me.

Anyway, I'm not proposing this as an alternative, just as an example of doing it only in the template and the code it calls.

Comment 10

[Steve Fink [:sfink] [:s:]]

Attachment: (part 2/2) Make overflow custom fields expandable

Comment 11

[Daniel Veditz [:dveditz]]

When it was broken bug numbers, plain words, and some aliases continued to work
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=123456%2C147777
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=topcrash
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%5B%5Breminder ([[reminder means sum,sw:[reminder)
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3ANSS (:NSS means prod,comp:NSS)

Searches that used field syntax ("foo:bar") failed
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A%5Breminder
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=prod%3ANSS
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=prod%3DNSS

I did try the : and = operators, didn't try any date relations so I don't know if operators like creation_ts>1w were broken or not

Comment 12

[Daniel Veditz [:dveditz]]

"broken" meaning it did nothing until I finally got a stream timeout or upstream request timeout error page (from Fastly I guess?). The equivalent queries in regular advanced query format worked fine and returned quickly. The timeout was not because they were inherently slow queries

Comment 13

[Daniel Veditz [:dveditz]]

There's a longstanding problem that might make sense to roll into this fix if you're changing the fields display anyway (or maybe not). If you use an invalid field name (e.g. quicksearch foo:bar) you get an error from bugzilla that says

There is a problem with your search:
foo is not a valid field name.
The valid field names are listed here.

That link sensibly references #fields, but you end up at the top of the page because the input field is given focus. If you reload (regular, not shift-reload) then you do end up at the fields list. Assuming the focus is being put on the field via script, maybe the script should check location.hash and only set the focus if the hash is empty.

If you're going to implement the field list as a default-closed widget then maybe expand it if location.hash is "#fields". If the list is always partially open (only the repetitive ones closed) then don't worry about it.

Comment 14

[Daniel Veditz [:dveditz]]

 +   # Get a list of active flags to determine which ones to include in the quicksearch map
 +   my $active_flags = Bugzilla::Extension::TrackingFlags::Flag->match({ is_active => 1 });
 +   my %active_flag_names = map { $_->{name} => 1 } @$active_flags;

Does that mean inactive fields wont work in quicksearch at all?! I don't mind hiding them on the help page but I quicksearch on old release status/tracking fields all the time! Sure, security and release management is an uncommon use case, but it's an important one and this is our tool to make those kinds of use cases better/possible. And "old" means "4 weeks ago tops" because we deactivate the previous release as soon as the current release is shipped.

Comment 15

[David Lawrence [:dkl]]

(In reply to Daniel Veditz [:dveditz] from comment #14)

 +   # Get a list of active flags to determine which ones to include in the quicksearch map
 +   my $active_flags = Bugzilla::Extension::TrackingFlags::Flag->match({ is_active => 1 });
 +   my %active_flag_names = map { $_->{name} => 1 } @$active_flags;

Does that mean inactive fields wont work in quicksearch at all?! I don't mind hiding them on the help page but I quicksearch on old release status/tracking fields all the time! Sure, security and release management is an uncommon use case, but it's an important one and this is our tool to make those kinds of use cases better/possible. And "old" means "4 weeks ago tops" because we deactivate the previous release as soon as the current release is shipped.

Yes I missed that in my original review so in comment 6 I requested that we do not change that so old inactive fields can still be queried.