Open Bug 437096 Opened 17 years ago Updated 11 years ago

checksetup.pl change NA/NA group fields for products into Shown/NA if group_control_map table is empty

Categories

(Bugzilla :: Installation & Upgrading, defect)

Product:
Bugzilla
Component:
Installation & Upgrading
Version:
3.0.2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

People

(Reporter: again, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080428 Firefox/2.0.0.14 Build Identifier: Bugzilla 3.0.2 I have created groups which I have set to NA/NA for all products. These are set to the default Shown/NA when running checksetup.pl. Reproducible: Always Expected Results: Leave the visibility as I set it.
You have to tell us a bit more about your config. Do groups have the same name as products? Is the useentrygroupdefault parameter turned on? Are all groups set to NA/NA affected?
OS: Linux → All
Hardware: PC → All
Version: unspecified → 3.0.2
* Groups have a different name as products. * useentrygroupdefault is turned off * All groups set to NA/NA are affected, but I have set all groups to NA/NA. (I'm using them to put users in certain groups and to share searches with them depending on which group they belong to -- this is probably not the thing groups are intended for.)
If there is at least one group which doesn't have NA/NA, are other groups set to NA/NA still affected? (I may have an idea)
I have two groups. I have set one group to Shown/NA and the other to NA/NA. After running checksetup.pl, the one group remained at Shown/NA and the other at NA/NA. Then I changed the Shown/NA group to NA/NA and ran checksetup.pl, and both groups remained in NA/NA -- so I cannot reproduce it anymore. Strange...
I will still give it a look when I have some time.
Keywords: qawanted
Today I noticed that all groups of one product were in Shown/NA again! I noticed it after one new bug was reported there -- it is the first bug report in this product since May. Maybe the flags can only change after a bug was reported in a product?
Christian, can you reproduce the issue with Bugzilla 3.4.4?
Hum... yes I can reproduce, using 3.4.4+. STR: 1) create a fresh new installation 2) create a group 3) note that editproducts.cgi lists the group as NA/NA (for the unique product TestProduct) 4) run checksetup.pl 5) note that editproducts.cgi now lists the group as Shown/NA
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: qawanted
Target Milestone: --- → Bugzilla 3.4
OK, I found the culprit. Bugzilla::Install::DB::_setup_usebuggroups_backward_compatibility() populates the group_control_map table if it's empty, see bug 147275 (was checked in in Bugzilla 2.18).
justdave, for some reason I don't really understand, asked joel in bug 185760 to make all groups be Shown/NA for all products no matter what, if the group_control_map table is empty. joel/justdave: ping? :)
Because that's how all groups worked prior to the new group system being implemented, back when the groups were just bitfields. They weren't product-specific, and all groups had a checkbox.
I would venture to say that should depend on upgrading from a pre-2.16 schema, if it's doing that any time the group_control_map is empty it sounds like it's not checking something correctly. A proper check might be to set a flag to say whether it needs doing or not if the groups table doesn't exist, before checking for the condition of creating the groups table.
Okay. So I suppose the question, then, is why is _setup_usebuggroups_backward_compatibility two steps below _convert_groups_system_from_groupset (with the two intervening items being unrelated)?
Yeah, I think we should only call _setup_usebuggroups_backward_compatibility() from within _convert_groups_system_from_groupset(), and only if $dbh->bz_column_info("profiles", "groupset") is true. joel?
Bugzilla 3.4 is now restricted to security bugs. We will retarget this bug (to 3.6 or later) when it's fixed.
Target Milestone: Bugzilla 3.4 → ---
justdave: is this still in need of fixing? Gerv
Flags: needinfo?(justdave)
Summary: checksetup.pl change NA/NA group fields for products into Shown/NA → checksetup.pl change NA/NA group fields for products into Shown/NA if group_control_map table is empty
Yeah, looks like it. checksetup.pl is trying to perform an upgrade step from 2.16 that doesn't need doing on fresh installs.
Flags: needinfo?(justdave)
You need to log in before you can comment on or make changes to this bug.