Closed Bug 185760 Opened 18 years ago Closed 18 years ago
New group system doesn't upgrade transparently if usebuggroups = 0
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?
Status: NEW → ASSIGNED
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)
This should be tried by some usebuggroups=0 sites
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+
18 years ago
Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.210; previous revision: 1.209 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.