147055 - Allow a search on a range of bug_ids (e.g. 1..100 or 1-100)

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, enhancement)

Description

[Steve Fuhrman]

This is a modification to buglist.cgi.

It allows input such as:

  1..3,5,8-10

which will result in the expected bugs being selected:
  1,2,3,5,8,9,10

Note that multiple ranges and ".." or "-" are allowed.


This is completely different from the patch I submitted in bug #146890
which was unfortunately very flawed.

This patch works by only changing what's sent to the SQL query instead
of changing what was input to buglist.cgi (this is much safer).

Comment 1

[Steve Fuhrman]

Attachment: Patch for buglist.cgi 2.14.1 made with diff -u

This patch I hope is worth looking at.

Comment 2

[Dave Miller [:justdave]]

If you're updating an existing patch, please post it to the same bug with the
original.  Hit the "Create a New Attachment" link on the other bug, make sure
you check off the "obsolete" mark for the old one on the upload form.

*** This bug has been marked as a duplicate of 146890 ***

Comment 3

[Dave Miller [:justdave]]

Hmm, bugzilla.mozilla.org hasn't picked up the fix to let uploaders obsolete
their own attachments.  Swapping duplicates to prevent the uploader having to
upload the patch over again.

Comment 4

[Dave Miller [:justdave]]

*** Bug 146890 has been marked as a duplicate of this bug. ***

Comment 5

[Jouni Heikniemi]

Marking (patch, review) per comment 1; reassigning to patch author.

Comment 6

[Jouni Heikniemi]

Comment on attachment 85056 [details] [diff] [review]
Patch for buglist.cgi 2.14.1 made with diff -u

buglist.cgi has been rewritten since 2.14, and I cannot apply the patch cleanly
now, thus needs-work. Do you have plans to upgrade your code to 2.16 codebase,
or would you like somebody else to look at it?

Comment 7

[Jouni Heikniemi]

The author said to me in email:

--
Let me take another look at this.  I ran into some issues when you combined
this patch with complicated queries.

In fact, it's probably best to close this as "needs more work" and I'll
try again with 2.16.

I'll upgrade from 2.14.1 and then try again with more thorough testing.
--

So let's wait for that, now. Unreviewable until that.

Comment 8

[Shane H. W. Travis]

Updating the Summary to be more helpful, adding myself and Callek to this bug 
since he was looking for an open bug on this very topic.

Comment 9

[Frédéric Buclin]

*** Bug 282730 has been marked as a duplicate of this bug. ***

Comment 10

[Mats Palmgren (inactive)]

I'd like to see this fixed too.  I would prefer 1-100 over 1..100, since
dash is also used in Bonsai (cvsblame.cgi) &mark ranges for example.

Comment 11

[miketosh]

After 30 minutes or so of guessing at Perl's syntax, here
is the fix, for the Bugzilla/Search/Quicksearch.pm:

############# Change: ############# 
    # Remove leading and trailing commas and whitespace.
    $searchstring =~ s/(^[\s,]+|[\s,]+$)//g;
    ThrowUserError('buglist_parameters_required') unless ($searchstring);

    if ($searchstring =~ m/^[0-9,\-\s]*$/) {
        # Bug number(s) only.

        # Allow separation by comma or whitespace.
        $searchstring =~ s/[,\s]+/,/g;
############# To: ############# 
    # Remove leading and trailing hyphens, commas, and whitespace.
    $searchstring =~ s/(^[\s,\-]+|[\s,\-]+$)//g;
    ThrowUserError('buglist_parameters_required') unless ($searchstring);

    if ($searchstring =~ m/^[0-9,\-\s]*$/) {
        # Bug number(s) only.

        # Replace number ranges
        while ($searchstring =~ /((\d+)\-(\d+))/) {
          my @numarr;
          foreach ($2..$3) {
            push @numarr,$_;
          }
          my $numlist = join ',',@numarr;
          $searchstring =~ s/$1/$numlist/;
        }

        # Allow separation by comma or whitespace.
        $searchstring =~ s/[,\s]+/,/g;
###################################### 

I've added this to my bugzilla installation, and IT WORKS PERFECTLY!
buglist.cgi?quicksearch=1,3-6,104-105,104-
Will return the best subset of 1,3,4,5,6,104,&105

Comment 12

[hacksaw]

What are the chances of this getting into a point release of some kind, instead of having to wait for the next big release?

Comment 13

[timeless]

Attachment: ranges!

algorithm based on [e-mail]'s suggestion

Comment 14

[Vlad Dascalu]

Comment on attachment 274736 [details] [diff] [review]
ranges!

+        push(@specialchart, ["bug_id", $type, join(',', $bug_ids))]);

This line causes the entire Bugzilla to crash as the "))" instead of ")" prevents Perl to compile the code.

     if ($searchstring =~ m/^[0-9,\s]*$/) {
         # Bug number(s) only.
 
+        $searchstring = Bugzilla::Search::expand_ranges($searchstring);

You need to modify the regexp here in order to allow room for "-" if you want it expanded later on. Due to this, quicksearch range-expand is unusable with the current patch applied.

Looks good otherwise.

Comment 15

[timeless]

Attachment: -punctuation

Comment 16

[Max Kanat-Alexander]

  I am inclined not to approve this, actually, because it adds code that doesn't seem to be useful to lots of people. Code doesn't "just sit there", it has to be read and maintained, so adding code that doesn't actually assist more than 5% of users isn't a good idea.

  The best explanation I've seen of this point is here:

  http://ometer.com/features.html

Comment 17

[Frédéric Buclin]

joel said in bug 282730 comment 1 that this would be a good RFE, and I also don't see any problem implementing this feature. I would just like joel to look at this patch and tell us if it's implemented the way he wants.

Comment 18

[hacksaw]

Max: I agree with the idea that code that doesn't help a lot of people isn't a good candidate for inclusion, but I have to wonder how you came to the conclusion this feature doesn't.

Comment 19

[Joel Peshkin]

Comment on attachment 276307 [details] [diff] [review]
-punctuation

I hate to be contrary, but as soon as this syntax is available, it will be used for ranges like 100000-200000.   This must not be allowed to expand to  a list of 100K integers (which will not only be slow but break the sql servers) but, rather, should expand to a check against the lower and upper limit of the range.

That said, it would be very handy to have this feature, though we need to publicize the syntax so users understand it.

Comment 20

[timeless]

that's nice. how do i figure out if a field is numeric? I need a way to distinguish TM 1-2 (string) from Bugs/Attachments 1-2 (range)

I think this means either changing anyexact to recognize ranges against numerics.
I'd end up using something like this:
push @ranges, "($ff >= $lower AND $ff <= $upper)";
$range = join " OR ", @ranges;

with an IN () for any that aren't ranges.

Comment 21

[Joel Peshkin]

I think this is best done by 
1) defining a new verb that is used specifically for lists of numbers, ranges of numbers, and aliases.
2) making the "bugs numbered..." form use the new verb
3) define and implement a quicksearch syntax that makes it usable from there

Comment 22

[hacksaw]

Wow.

You know, all I was hoping for was that in the advanced search, where you can put in a list of bugnumbers, that you'd be able to but in ranges:

22,48,93-107,812

I don't think you'd have to have a special grammar for that, or have to worry about other search terms confusing things.

Comment 23

[Joel Peshkin]

Exactly, so items number 1 and 2 of comment 21 should be in the patch and we can leave item 3 for a flash of inspiration someday.

Comment 24

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 25

[miketosh]

(In reply to comment #19)
> I hate to be contrary, but as soon as this syntax is available, it will be used
> for ranges like 100000-200000.   This must not be allowed to expand to  a list
> of 100K integers (which will not only be slow but break the sql servers) but,
> rather, should expand to a check against the lower and upper limit of the
> range.

Uh, so this couldn't be done now by users pasting a range of 100000 numbers into the bug_id field in the advanced search???

This would be a GREAT patch to take for 3.2.  It has been ignored for long enough :-(

I think the patch provided is good enough, no?

Comment 26

[Joel Peshkin]

(In reply to comment #25)
> 
> I think the patch provided is good enough, no?
> 

Close, but we shouldn't be adding new bugs that cause serious  breakage.

The same way as we currently allow the use of a regular expression using the "regexp" verb or the use of a list of words using the "allwords" verb, we need an "inrange" verb.  Once we have that verb, then the function in Search.pm implementing that verb can parse the $v string for (\d+)-(\d+)  or , perhaps, (\w+)-(\w+) and generate 2 SQL restrictions, one for the upper end and the other for the lower.

Comment 27

[miketosh]

how does a new (In reply to comment #26)
> The same way as we currently allow the use of a regular expression using the
> "regexp" verb or the use of a list of words using the "allwords" verb, we need
> an "inrange" verb. 

How does this require a new verb?  Are you expecting this to be used in the boolean charts more than in the "bugs numbered" or quicksearch boxes?

Comment 28

[miketosh]

How about using BETWEEN?  Is that standard SQL, or only MySQL?

Comment 29

[:glob ✱]

this is possible to do with advanced search:

https://bugzilla.mozilla.org/buglist.cgi?j_top=AND_G&o1=greaterthaneq&o2=lessthaneq&v1=15806&v2=175416&f1=bug_id&resolution=---&query_format=advanced&f2=bug_id&component=Query%2FBug%20List&product=Bugzilla

this query shows all open bugs in numbered between 15806 and 175416 in the 'query/bug list' bugzilla component.