Boolean Chart Redesign

[Max Kanat-Alexander]

	Hey folks. 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.

	Does this sound good to everybody? Are there any questions, concerns,
suggestions?

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.