Closed Bug 185760 Opened 21 years ago Closed 21 years ago

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


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




Bugzilla 2.18


(Reporter: jouni, Assigned: bugreport)



(1 file)

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.
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?

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)
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?
No, I said Default/NA, and that's what I meant.
So, basically, the desired behavior is to do exactly what checksetup does now,
except no make it depend on makeproductgroups (formerly usebuggroups).

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)
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.18
This should be tried by some usebuggroups=0 sites
Attachment #109701 - Flags: review?(jouni)
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.
Attachment #109701 - Flags: review?(jouni) → review+
Flags: approval+
Checking in;                                
/cvsroot/mozilla/webtools/bugzilla/,v  <--
new revision: 1.210; previous revision: 1.209
Closed: 21 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.