Boolean Chart Redesign

[Bernd Groh]

Max Kanat-Alexander wrote:
> 	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).
>   

First of all, I think it's great that this is finally being looked at. 
I've been extremely frustrated with the boolean charts on a number of 
occasions, and it's good to hear things are happening here. Yet, I'm not 
so sure whether above approach really makes the query less complicated, 
or significantly shorter. As to the length, in my experience, the length 
issue is most often caused not by the slightly longer parameter names, 
but by the length of the data values. Shortening the parameter names 
doesn't really do much if you've got a data value containing a few 
hundred components. I don't think above approach would help addressing 
that issue (and I'm not sure it really can be addressed, other than by 
using POST instead of GET). As to how much less confusing this query 
would be, looking at it, it actually appears even more confusing to me. 
What I'd like to ask, is whether we really need to distribute the query 
over so many different parameters. Wouldn't there be a way to simply 
have the url, to use above example, look like this:

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

To me, that would make the query less confusing. That would make it a lot easier to construct queries. And how would I like the UI to look? Well, it would have two parts. One part most people are familiar with, buttons, operators, and text fields to construct the query, and a big massive text box that gets filled as you construct the query. And if you don't really like to use all these buttons, fields and text boxes, then you can just write the query straight into the text box, and that's that.

And no, I don't necessarily expect everyone to agree with me, but I figured I may as well throw out there what I'd like to have it look like. And I really don't care what the back-end looks like as long as it can deal with valid boolean queries (preferably submitted in a single parameter).

Cheers,
Bernd


> 	* 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
>