638623 - (bz-andor) Redesign custom search to be an independent series of logical clauses (AND/OR)

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Max Kanat-Alexander]

Here's my original description of this enhancement, from when I proposed it on the developers list:

    So, the Boolean Charts are great, they're powerful, and they've been an important part of Bugzilla since 2000. However, the Boolean Charts have some problems:

	* The way that AND, OR, and multiple charts work is really confusing. I didn't fully understand it until I fully understood Search.pm, which very few people understand.

	* You can't really do arbitrary AND/OR groupings. For example, there's
no way to do this search with the Boolean Charts:

	(a AND b) OR (c AND d)

	* They generate extremely long URLs, because the URL parameters look
like field0-0-0, type0-0-0, and value0-0-0. Sometimes these URLs are too long for the web server to deal with, and people can't do the searches they want to.


	As such, I'd like to propose a redesign of what we currently call "boolean charts" into a system that is able to do arbitrary logical groupings. Here's how it will work:

	URL parameters will look like:

	f1=bug_id&o1=equals&v1=1234&j2=OR&n2=1&f2=short_desc&o2=substring&v2=test

	"f" means "field", "o" means "operator", "v" means "value", "j" means
"join" (either AND or OR), and "n" means "not". That URL is a search for
bugs where:

	the bug_id equals 1234
	OR NOT (the summary contains the string "test").

	There will be two "special" fields for the "f" parameter: OP and CP,
which mean "open paren" and "close paren". These will allow logical groupings, with an infinite amount of nesting. For example, if you want to do:

	( (bug_id = 1 AND short_desc = 'a') OR NOT (bug_id = 2 AND short_desc =
'b') ) AND priority = 'Low'

	The URL would look like (split on to multiple lines, indented,  and
with & removed to help readability):

	f1=OP
		f2=OP
			f3=bug_id o3=equals v3=1
			j4=AND
			f4=short_desc o4=equals v4=a
		f5=CP
		j6=OR n6=1
		f6=OP
			f9=bug_id o9=equals v9=2
			j10=AND
			f10=short_desc o10=equals v10=b
		f11=CP
	f12=CP
	j13=AND
	f13=priority o13=equals v13=Low

	And even with all that extra OP/CP/AND/OR stuff, I'm pretty sure the
resulting URL is still shorter than the equivalent boolean charts URL (which would be impossible anyway).

	* The boolean chart UI will get two new buttons: "(" and ")". The "Add
a new chart" button will be removed.

	* Certain fields like "flags" want to all refer to the same flag if you
specify multiple criteria. For example, if you search for "Flags equals review?" AND "Flag Requestee equals mkanat", you probably mean "find me bugs where the review flag has a requestee of mkanat". In the new system, this will be accomplished by "associating" any fields that are within parens. (Formerly, this was accomplished by associating any fields within the same chart, which could be pretty confusing for users.) So within any set of parens, all searches for the Flag fields will be about one flag.
	Alternately, we could come up with some specific mechanism for people to associate things, which might be better, but I'm not thinking of anything that would be simple enough in the code and the UI other than the system I just proposed.

	* Adding a different "join" than the previous "join" without specifying
an "open-paren" would be an error. That is, this is too ambiguous to allow: a AND b OR c AND d. Did the user intend "(a AND b) OR (c AND d)", or did they intend "a AND (b or C) AND d"?
	The UI will handle this automatically by closing the existing parentheses set if you specify a different operator than you last used.
It will still be possible to generate improper URLs, though, which should be throw an error to prevent unexpected results from ambiguous logical groupings.

	* Saved Searches and New Charts series can both be upgraded to this new
system automatically, most likely with no loss of functionality, within the "convert_old_params" method in Search.pm, so there should be little need for people to manually fix their saved searches or any URLs that they have linked to Bugzilla using the old system. We may be able to do something similar to continue supporting people's Default Queries, if they involve boolean charts, but that's a lower priority.

	* Once the system is in place, QuickSearch can be upgraded to support
parentheses. We will need some better parsing code to support this properly, possibly using some CPAN module.

Comment 1

[Max Kanat-Alexander]

I'm going to be doing this work in many separate bugs, but I will be doing it all on a *branch*. The reason to do it on a branch is that until I'm done, there will be some features missing, and I don't really want to hold up any development releases while I'm working.

Comment 2

[Max Kanat-Alexander]

Slight design change: the "join" (j1, j2, etc.) arguments will only be looked at when the "field" is "OP". That is, we will always join everything within a set of parentheses one way, which shortens our URLs even more. Also, we default to AND, so AND doesn't need to be specified.

Comment 3

[Frédéric Buclin]

Status of this bug? 4.2 or 5.0?

Comment 4

[Max Kanat-Alexander]

Definitely 4.2; this is the major Search blocker.

Comment 5

[Max Kanat-Alexander]

This is done. :-)

I've filed Bug 677757 (better search of flags, attachments, comments, etc.) for a follow-up. Extra Quicksearch features are probably covered by various QS bugs already filed.