95430 - Reopening en masse fails.

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect, P1)

Description

[Matthew Tuck [:CodeMachine]]

There is an option for reopening on the bulk change page.  However it doesn't
work.  It references the "id" parameter several times which does not exist for
bulk changes.

It looks like this problem _may_ have been introduced during the duplicates
table introduction, as there's some code there that references the duplicates
table.  Or that just may have added more broken code.

This should be looping through @idlist or some such.

There's also similar code for mass duplicate marking.  Although this probably
can't get called from the UI, it probably still can be called by entering a
special URL.  It should be dealt with too.

Comment 1

[Matthew Tuck [:CodeMachine]]

OK, this is Gervy's fault.  Gerv please take a look at the eventual patch here
to not make the same misteak again.

Anyway, to whomever does this, Dave said apparently there's an $id variable
available so we will want to use that.

Then the SELECT and DELETE should probably be next to each other (and indented
properly).

There's also code down lower that was pre-Gerv which handles trying to mass
resolve dupe.  This isn't allowed, so it does a (!defined($::FORM{'id'}) ||
...), which is OK but it gives the error "can't mark bug dupe of itself". 
Instead it should say something like "can't bulk change resolve dupe" or
whatever.  Or alternatively use $id and support it, at least on the back end.

Comment 2

[Gervase Markham [:gerv]]

Where are we looking, here? 

Am I expected to do something about this? :-)

Gerv

Comment 3

[Matthew Tuck [:CodeMachine]]

We're on top of it but you can do a patch if you want.  See URL.

Comment 4

[Dave Miller [:justdave]]

correcting version field lost in product move

Comment 5

[Matthew Tuck [:CodeMachine]]

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

Comment 6

[Dave Miller [:justdave]]

Matty, who's "we"?

Comment 7

[Matthew Tuck [:CodeMachine]]

I think it was you and me - see comment #1.  But it didn't seem to be as simple
as you implied at the time, so I never got anything done on this.

Comment 8

[Dave Miller [:justdave]]

OK, since we're not sure what we were doing on this and we don't have a patch
yet, pushing this to 2.18

Comment 9

[Dave Miller [:justdave]]

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

Comment 10

[Dave Miller [:justdave]]

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

Comment 11

[Andrew Over]

Attachment: quick and dirty hack

This is a quick hack along the lines of the suggestion in the original
description.  I'm not completely familiar with the source, so it might be
totally wrong, but seems to work ok here.

Caveat Emptor.

Comment 12

[Bradley Baetz (:bbaetz)]

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

Comment 13

[Bradley Baetz (:bbaetz)]

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

Comment 14

[Jeff Hedlund]

Attachment: Patch v.1

I worked on this because I thought it might have been my fault.. :)  Anyway,
here's what I worked on for the dup bug 177627.

Comment 15

[Joel Peshkin]

Comment on attachment 104728 [details] [diff] [review]
Patch v.1

r=joel

Comment 16

[Dave Miller [:justdave]]

Comment on attachment 104728 [details] [diff] [review]
Patch v.1

I think this is hiding the problem instead of fixing it.  Your resulting query
is going to have bug_id = '' in the case of a mass query, which will pass as
valid SQL, but isn't getting us the results we want.  We need to get the actual
bug number in that SQL there.

Comment 17

[Matthew Tuck [:CodeMachine]]

Also I think mass reopen needs to clear the duplicates table if appropriate.

Comment 18

[Dave Miller [:justdave]]

It's trying to do that in the code we're looking at, except it's not, because
the bug_id isn't valid at that point if it's a mass-change.

What we're discussing on IRC right now is checking later when we have individual
bug IDs if the status is being changed to REOPENED to clear the duplicates table
regardless.  If the bug is being reopened it can't be a duplicate anymore,
whether it was a duplicate to begin with or not, and if it wasn't before, your
DELETE FROM duplicates will just return 0 rows changed.

Comment 19

[Jeff Hedlund]

Attachment: Patch v.2

Ok, moved duplicate deleting to the bug id loop.

Comment 20

[Dave Miller [:justdave]]

Comment on attachment 104731 [details] [diff] [review]
Patch v.2

tested on landfill, it works as advertised, and doesn't pollute the dupes
table.

r=justdave

Comment 21

[Joel Peshkin]

Comment on attachment 104731 [details] [diff] [review]
Patch v.2

2xr=joel

Comment 22

[Joel Peshkin]

Checking in for Jeff:

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.162; previous revision: 1.161
done                                     

Comment 23

[Dave Miller [:justdave]]

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

Comment 24

[Dave Miller [:justdave]]

nominating for 2.16.5 because this is a low-risk fix for a functionality issue.

Comment 25

[Dave Miller [:justdave]]

Attachment: Patch against 2.16 branch

Comment 26

[Gerard Beekmans]

Patch works, thank you very much.

Comment 27

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

Comment on attachment 135043 [details] [diff] [review]
Patch against 2.16 branch

Works, r=myk

Comment 28

[Dave Miller [:justdave]]

checked in on 2.16 branch:

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.125.2.9; previous revision: 1.125.2.8
done

Comment 29

[Dave Miller [:justdave]]

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