111271 - Ability to exclude/include results of one query from another.

Status: NEW

(Bugzilla :: Query/Bug List, enhancement, P4)

Description

[Asa Dotzler [:asa]]

Problem: sometimes I run several queries trying to find a bug. I look at the
results of a query, realize that my bug isn't there and run another query.
reading through the buglist from the second query I see some of the results from
the first query. if I run several queries with long buglists I end up wasting a
lot of time scanning over the same bugs in buglists. 

Solution: if I could run a query, see that my bug is not there and run a second
query excluding the results of the first query I could save some time. 

Implementations: I haven't thought too much about this but it could be something
like save the results of a query as a named list of bug IDs. then when I run the
second query there could be a "exclude buglist foo" option. If a third query was
necessary I could name the results of the second query and in the third query I
could exclude "foo" and "bar".

I can currently do this with one list by regetting the list then doing an edit
query and selecting exclude bugs numbered but that only works once and takes too
much effort.

Comment 1

[Simon Montagu :smontagu]

It would also be useful to do the exact opposite, and do a new search only in
the bugs returned from the original search, like Google's "Search within
results". The implementation of the two RFEs would be much the same.

Reassigning to justdave per discussion on #mozwebtools

Comment 2

[Dave Miller [:justdave]]

The implementation that was discussed on #mozwebtools would be almost painfully
simple....

There's an "include only bugs numbered" box on the query form, also an "exclude
bugs numbered".  The two use the same text entry box, and have a popup menu to
choose whether you're including or excluding.  On the bottom of the buglist.cgi
page, right next to the "Edit this query" link, you have a "Search within
results" link, which does nothing but link back to the query form with the list
of bug numbers from the current result set prefilled in that text box (defaulted
to "Include only bugs numbered" on the popup).  If you want to exclude those
results instead of search within them, it's a simple matter to toggle the popup.

Comment 3

[Dave Miller [:justdave]]

Attachment: Patch v1

Comment 4

[Dave Miller [:justdave]]

Attachment: Patch v2

fixing a 2-character typo in the first patch

Comment 5

[Dave Miller [:justdave]]

Comment on attachment 127413 [details] [diff] [review]
Patch v2

Requesting review from Myk since this is a UI change to the navigation bar at
the bottom of the query page.  The diff isn't as bad as it looks...  most of is
is changing the indent on the HTML that gets moved inside the table.

Comment 6

[Dave Miller [:justdave]]

Attachment: Patch v2 with diff -uw for review purposes

Comment 7

[Asa Dotzler [:asa]]

There's one big problem with this approach (I already use this method - using a
bookmarklet to convert the buglist into a comma separated list of bugs and
feeding that back into the exclude field of query.cgi):

Simply dumping a list of bugs into the include or exclude field in the query
page, one very quickly runs into a URL length limit (I think the Apache server
sets this). I think the limit is something around 8000 characters.  A typical
bug is 9 characters long including the escaped comma and the stock "empty" query
is over 600 characters long so this limits the number of bugs that can be fed
back through query.cgi to something around 800. 

I guess it would be a serious task when compared to reusing the existing
functionality but what we really need to be able to do is feed the two queries
to the server and let it process both, do the minus and return a buglist. 

Comment 8

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 127413 [details] [diff] [review]
Patch v2

Asa:

>If a third query was necessary I could name the results of the second query 
>and in the third query I could exclude "foo" and "bar".

Note that the current patch doesn't provide this functionality.  Given the
simplicity of this patch, the anticipated complexity of one that does provide
the functionality, and the likelihood that third queries are rare, I think
that's ok for now.  Asa, do you concur?


Dave:

>If you want to exclude those results instead of search within them, 
>it's a simple matter to toggle the popup.

Simple, yes, but discoverable, no, at least not for anyone who would exclude
bugs sometimes but not "search within results".  There should be some UI for
excluding results just as there is for searching within them, perhaps: "search
[within] or [excluding] these results"


Asa:

>Simply dumping a list of bugs into the include or exclude field in the query
>page, one very quickly runs into a URL length limit

One solution to that problem would be for query.cgi to check the length of the
include/exclude field and turn the form into a post request if the field length
(taking into account the other fields on the form) is dangerously close to the
URL length limit.  This takes away bookmarkability, but presumably the purpose
of these queries is to find specific bugs, not create a list of bugs that you
regularly return to, right?

That leads me to the question of how often this functionality will be needed
once full text search (bug 145588) goes in.  Asa, has use of the test
installation for that patch affected your searching habits in this regard?



>Index: template/en/default/list/list.html.tmpl

>+  [%# We do this in a table because we have two forms that submit to two different
>+      places, and normally, </form> breaks to a new line, so we put each in a
>+      table cell to keep them in the same horizontal row %]

The solution to that is to turn the forms into line-level elements via CSS.

Comment 9

[Joel Peshkin]

Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.

Comment 10

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 11

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.