185760 - New group system doesn't upgrade transparently if usebuggroups = 0

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect, P1)

Description

[Jouni Heikniemi]

In 2.16 time, our system had a security group that spanned all the products. We
never used product-wise security groups, so we had usebuggroups &&
usebuggroupsentry == 0. That made Bugzilla::Config's UpdateParams set the new
param MakeProductGroups to 0. After this, Checksetup didn't bother flagging the
security group as being available for existing products, so I had to manually
set the MemberControl to Shown for all products.

This was ActiveState Perl 5.6.1 on Win2000 / IIS 5, but I don't think it's an OS
issue anyway.

Comment 1

[Joel Peshkin]

So, is desired behavior that all groups for all products become
Shown/NA ??

The only problem I have with doing this is that I suspect many people will move
their DBs to a new Bugzilla and not bring data/params along.  If they do that,
once they have run checksetup, they will not be able to get auto-coverted to use
buggroups unless they manually DROP the group_control_map and rerun checksetup.
 Today, the map does not even get created unless the user has buggroups enabled
or goes into editproducts and starts editing group_control_map.

How do we want this to work? 

Should we put something in that prevents auto-construction of group_control_map
if params was created from nothing?

Comment 2

[Dave Miller [:justdave]]

All groups that match a product name should become Default/NA in the product
they match during the upgrade, whether usebuggroups was set or not. 
Usebuggroups, in true function, was identical to makeproductgroups in the new
setup, with a few small differences.  You could turn usebuggroups off, and
products would still be protected, you just wouldn't get a new group when you
created a new product.  Similarly, it was quite possible to create normal groups
long before product groups was even a concept, so any existing non-system groups
should be getting converted to Shown/NA on all products period, regardless of a
param setting.  (unless of course group_control_map already exists)

Comment 3

[Joel Peshkin]

That would be SHOWN/NA, right?

The only people that would trip over this are people who start with an old DB
and a new params file and don't have makeentrygroupsdefault enabled before
running checksetup.  Any ideas to protect them?

Comment 4

[Dave Miller [:justdave]]

No, I said Default/NA, and that's what I meant.

Comment 5

[Joel Peshkin]

So, basically, the desired behavior is to do exactly what checksetup does now,
except no make it depend on makeproductgroups (formerly usebuggroups).

??

Comment 6

[Dave Miller [:justdave]]

Yeah, that'd probably work.  I think that's the main thing, is that usebuggroups
didn't have to be set before for you to actually be using bug groups :)  The
param name was confusing (so I'm glad we got rid of it)

Comment 7

[Joel Peshkin]

Attachment: Patch - builds group_control_map even if usebuggroups is disabled

This should be tried by some usebuggroups=0 sites

Comment 8

[Dave Miller [:justdave]]

Comment on attachment 109701 [details] [diff] [review]
Patch - builds group_control_map even if usebuggroups is disabled

This diff is painful looking, but it's just diff playing games.  If I pull this
up in side-by-side view in FileMerge it's obvious that it's the same code with
the if block removed from around it.  This is pretty harmless.

Comment 9

[Joel Peshkin]

Checking in checksetup.pl;                                
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.210; previous revision: 1.209
done