Last Comment Bug 107718 - masschange gives all changed bugs the groupset of the first bug in the list
: masschange gives all changed bugs the groupset of the first bug in the list
Status: RESOLVED FIXED
: dataloss
Product: Bugzilla
Classification: Server Software
Component: Creating/Changing Bugs (show other bugs)
: 2.15
: x86 Linux
: P1 blocker (vote)
: Bugzilla 2.16
Assigned To: Bradley Baetz (:bbaetz)
: default-qa
Mentors:
: 174041 (view as bug list)
Depends on: 68022
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-30 23:20 PST by Bradley Baetz (:bbaetz)
Modified: 2012-12-18 20:46 PST (History)
7 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (2.96 KB, patch)
2001-10-31 14:27 PST, Bradley Baetz (:bbaetz)
justdave: review+
jake: review+
Details | Diff | Splinter Review
use subtraction (1.83 KB, patch)
2001-11-13 17:14 PST, Bradley Baetz (:bbaetz)
no flags Details | Diff | Splinter Review
add correct bracketing, too (1.83 KB, patch)
2001-11-13 18:17 PST, Bradley Baetz (:bbaetz)
jake: review+
jake: review+
Details | Diff | Splinter Review
Backported patch for the 2_14_1-BRANCH (3.30 KB, patch)
2002-05-26 18:19 PDT, J. Paul Reed [:preed]
bbaetz: review+
matty_is_a_geek: review+
Details | Diff | Splinter Review

Description Bradley Baetz (:bbaetz) 2001-10-30 23:20:57 PST
myk, this should be considered for being a blocker for the b.m.o upgrade.

I noticed this happening once before, but just thought that the wrong button was
pushed.

If you do a mass change, then one of the options is to leave everything as it is
However, the code to handle this is run once, not once per bug (~ line 564 in
process_bug.cgi:

    } elsif ($::FORM{"bit-$b"} == -1) {
      # If we get here, the user came from the change several bugs form, and
      # said not to change this group restriction.  So we'll add this group
      # back in only if the bug already has it.
      if ($bughasgroup) {
        $::query .= " + $b";
      }
    }
For setting/clearing, this is OK, but not for keeping as is. I suspect (but its
late, and I haven't tested) that we just need to set groupset to groupset in the
init code, rather than 0, and then this branch of the if statements should then
be a noop. Removing a group (ie !$bughasgroup && $::FORM{"bit-$b"} == 1) should
then just subtract the bit.
Comment 1 Bradley Baetz (:bbaetz) 2001-10-30 23:24:20 PST
Oh, and $bughasgroup but no form element should imply keep-as-is, regardless of
whether or not the user is in the group.
Comment 2 Bradley Baetz (:bbaetz) 2001-10-31 13:35:32 PST
Actually, my suggestion doesn't work, because obviously the initial groupset is
different.

I'm going to keep two vars, a groupsetadd and a groupsetdel, and then update teh
bugs groupset (in the sql statement) to be:

(groupset & ~groupsetdel) | groupsetadd

Taking
Comment 3 Bradley Baetz (:bbaetz) 2001-10-31 14:27:52 PST
Created attachment 55982 [details] [diff] [review]
patch
Comment 4 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-02 15:37:03 PST
Comment on attachment 55982 [details] [diff] [review]
patch

r= justdave
the perl compiles.  all tests pass.
I tested the SQL locally, and it works the way it's supposed to.
Comment 5 Jacob Steenhagen 2001-11-02 21:25:09 PST
Comment on attachment 55982 [details] [diff] [review]
patch

OK, it makes sence to me now... must've just taken some time to sink in :)

Anyway, it works as extected in all the tests I put it through...
r=jake
Comment 6 Bradley Baetz (:bbaetz) 2001-11-02 21:53:32 PST
Fixed
Comment 7 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-05 21:27:02 PST
MySQL < 3.23.5 doesn't support the ~ bitwise negation operator.

Landfill is now broken.  (Jake and I both appear to have 3.23.x at home where we
tested this - Landfill has 3.22.32)
Comment 8 Dave Miller [:justdave] (justdave@bugzilla.org) 2001-11-05 21:33:16 PST
Current thinking on this is that the groupset math is all going to have to be
done over again for the groups schema change (since groups will be individual
entities instead of a bitfield), so if we hurry and get that in, this all won't
even matter.  In the meantime, Bugzilla only runs on MySQL 3.23.5 and newer.

Note that reopening this should not block the b.m.o upgrade because they're also
upgrading their MySQL server, and the new one will handle this fine.
Comment 9 Bradley Baetz (:bbaetz) 2001-11-05 21:47:13 PST
[midaired with dave]

Can we just up the mysql requirements? I suspect that the pgsql code would get a
lot nicer if we could use some of the ansi features. dkl - is that true?

Or we could just get the group patch in, but has anyone checked that we actually
still run with our current requirement of 3.22.5 ? ~ wasn't something I'd have
thought to check, since its a fairly basic operation to support if you claim to
support bitsets. Even if I had checked, its mentioned in the docs.

mysql 3.22.5 was released in August 1998. Thats over three years ago, which is a
Long Time on the net.

/me goes to comment on bug 87958
Comment 10 David Lawrence [:dkl] 2001-11-06 06:38:45 PST
>Can we just up the mysql requirements? I suspect that the pgsql code would get 
>a lot nicer if we could use some of the ansi features. dkl - is that true?

I am not sure when support for the ~ operator was brought into PostgreSQL but 
it is fine for the releases I am supporting for the PostgreSQL port (7.1.x).
Granted I still have to add in the int8() wrappers to make it work properly. The
new group scheme should work for any database. 

Upping the Mysql requirements for 2.16 in case the group changes do not make it
in would solve the problem in the short term.
Comment 11 Matthew Tuck [:CodeMachine] 2001-11-08 01:33:10 PST
Can we temporarily achieve ~ with subtraction?  ie for 32 bit numbers, not is
really (2 ^ 32) - X.
Comment 12 Matthew Miller 2001-11-08 11:26:15 PST
We're running mysql 3.22.32 on a production machine that can't really be
upgraded right now (maybe over the semester break, but maybe not til next
summer). I've currently made a workaround by doing the work in perl before
sending the query, but that's not very elegant, and I don't want to keep doing
it as more ~s creep into the code. :)
Comment 13 Bradley Baetz (:bbaetz) 2001-11-08 15:40:04 PST
See bug 87958. I can fix this case, I guess - using subtraction will work. But
there are features from 3.23 that we really want to use. For example, temporary
tables will be a faster way of doing some things, but they aren't available in
3.22. Theres also the lack of testing.
Comment 14 Bradley Baetz (:bbaetz) 2001-11-13 17:14:14 PST
Created attachment 57691 [details] [diff] [review]
use subtraction

This also reverts the temporary checksetup.pl change I added.

How does the use vars line I added work?
Comment 15 Andreas Franke (gone) 2001-11-13 17:50:33 PST
Thanks for the checksetup patch to re-allow mysql 3.22. There's one problem,
though, but I'm not sure if it's in your patch or if it's already in cvs:
Making a restricted bug public by unchecking all groups' checkboxes doesn't seem
to work. 
Comment 16 Andreas Franke (gone) 2001-11-13 18:07:10 PST
Actually, I managed to make my test bug public again, but I had to do this in
two steps. I had three groups: 
bit-512 (A) 
bit-256 (B)
bit-128 (C)
Going from [A][B] to none failed, but going from [A][B] to [C] or to [B][C]
worked, and going from [C] to none worked, too. Strange...
Comment 17 Bradley Baetz (:bbaetz) 2001-11-13 18:17:40 PST
Created attachment 57701 [details] [diff] [review]
add correct bracketing, too

Oops. Try this, instead
Comment 18 Andreas Franke (gone) 2001-11-13 20:10:08 PST
Better :-) Seems to work now. Thanks.
Comment 19 Jacob Steenhagen 2001-11-14 07:06:06 PST
Comment on attachment 57701 [details] [diff] [review]
add correct bracketing, too

Tested on 3.23 and 3.22 and it works great :)
r=jake
Comment 20 Bradley Baetz (:bbaetz) 2001-11-14 07:36:11 PST
Fix checked in.
Comment 21 J. Paul Reed [:preed] 2002-05-26 18:19:13 PDT
Created attachment 85131 [details] [diff] [review]
Backported patch for the 2_14_1-BRANCH

This patch is a combination of the two patches reviewed above, so for the
2.14.1 branch, it turned into an entirely different patch.

Even though both patches applied cleanly to the branch (when done in order,
D'oh!), I'll wait for r=/r2= before checking this in; I'm pretty confident I
got it right, but I want someone else to make sure I did.
Comment 22 Bradley Baetz (:bbaetz) 2002-05-27 21:29:35 PDT
Comment on attachment 85131 [details] [diff] [review]
Backported patch for the 2_14_1-BRANCH

This looks fine to me - its what I had before, at least.
Comment 23 Matthew Tuck [:CodeMachine] 2002-05-27 21:30:29 PDT
Comment on attachment 85131 [details] [diff] [review]
Backported patch for the 2_14_1-BRANCH

Works correctly in testing.
Comment 24 J. Paul Reed [:preed] 2002-05-27 21:40:15 PDT
Backported patch checked in:

Checking in process_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v  <--  process_bug.cgi
new revision: 1.96.2.2; previous revision: 1.96.2.1
done
Comment 25 Bradley Baetz (:bbaetz) 2002-10-11 18:09:40 PDT
*** Bug 174041 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.