Currently, buglist.cgi can take a number of common fields (e.g. platform=foo, op_sys=bar) as URL parameters, where you can specify the same parameter multiple times to search for any one of the values. Then, you have to use boolean charts for the rest. "The rest" includes all custom fields, and such commonly-searched things as flag, time tracking and groups. So people end up using boolean charts much more than they should. My suggestion is to change Bugzilla so that if it sees a URL parameter of foo=bar, and it doesn't recognize "foo" as one of the field names which are specially handled, it just turns it into a boolean chart of field-0-0-0=foo&type-0-0-0=equals&value0-0-0=bar . If there's multiple values, it ORs them together in the boolean charts way. (And if there are existing boolean charts, it obviously adds the extra ones on the end rather than overwriting!) So "&group=wibble" would turn into &field-0-0-0=group&type-0-0-0=equals&value0-0-0=wibble but "group=wibble" is a lot easier to write and create alternative HTML UIs for, because you just have <select name="group"><option name="wibble">Wibble</option>...</select> I was thinking of having this facility on the API, but then I thought "why don't we just make Bugzilla itself support it?". I asked LpSolit about this on IRC and he thought it made sense. Gerv
Just thinking about it again, couldn't you use QuickSearch to do that? I would prefer QS to generate the boolean charts itself rather than duplicating the code. I think it already understands most of the fields you may need, and it would be easy to add missing ones, if needed. For instance, "group:bugzilla-security" generates: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=group%3Abugzilla-security which works correctly.
But I can't (without scripting) create an HTML form which generates URLs in that style. The key gain here would be to allow people to more easily generate different or more specialist search UIs. It may well be that implementing this allows us to do some refactoring and remove code duplication. That would be fine. Gerv
This is a reasonable request, and probably wouldn't be that hard for a Search.pm hacker to implement.
Priority: -- → P3
Created attachment 409611 [details] [diff] [review] v1 Turns out I ran into a need for this myself! :-)
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Attachment #409611 - Flags: review?(gerv)
Comment on attachment 409611 [details] [diff] [review] v1 What's the logic behind excluding fields with a . in the name? Can you take the opportunity of adding that comment to explain when work_time is work_time and when it's actual_time? (And how it got that way and if we can fix it? :-) Otherwise, looks good. It's amazing that it's so simple :-) Gerv
(In reply to comment #5) > What's the logic behind excluding fields with a . in the name? fielddefs contains fields like "attachment.name", which don't always work with the normal charts. > Can you take the opportunity of adding that comment to explain when work_time > is work_time and when it's actual_time? (And how it got that way and if we can > fix it? :-) That comment is in Bugzilla::Search::COLUMNS, and writing the comment would be almost as involved as fixing the problem.
Attachment #409611 - Flags: review?(gerv) → review+
Thanks, gerv! :-) Checking in query.cgi; /cvsroot/mozilla/webtools/bugzilla/query.cgi,v <-- query.cgi new revision: 1.188; previous revision: 1.187 done Checking in Bugzilla/Constants.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v <-- Constants.pm new revision: 1.118; previous revision: 1.117 done Checking in Bugzilla/Search.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v <-- Search.pm new revision: 1.176; previous revision: 1.175 done
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Added to the release notes in bug 547466.
You need to log in before you can comment on or make changes to this bug.