279894 - checksetup.pl should set "Entry" access group for an product if paramerter useentrygroupdefault is set to on

Status: RESOLVED WORKSFORME

(Bugzilla :: Installation & Upgrading, defect)

Description

[Björn Teipel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

As discussed on Bug #279877, the migration from an older version of bugzilla to
2.18 should be changed. Each product should be marked as "Entry" for his owner
to prevent other users which are not allowed for this product to view it.

In my case, useentrygroupdefault was set to on at bugzilla 2.16.4 and the users
could only see the products where she/he could create bugs for.
This is very usefull, especially if you have external customers and they
shouldn't see other customers or even your internal products.
After migration to bugzilla 2.18.0, the behavior was lost.
Only after setting each product the "Entry" value for its own group solved this.

Reproducible: Always

Comment 1

[Marc Schumann [:Wurblzap]]

Hmmm, this might make 2.16 people refrain from advancing to 2.22 if they take 2.22 on a test ride and find their bugs open all of a sudden...

How can checksetup.pl find out which group to set the Entry flag for? (I don't know 2.16, so please bear with me if this is a dumb question.)

Comment 2

[Frédéric Buclin]

joel, Param('useentrygroupdefault') = 1 means that you can only see/edit a product if you belong to all groups associated with the product having ENTRY = 1, even if these groups are not mandatory, right? At least, that's what I understand when reading User::get_selectable_products().

On the other hand, checksetup.pl seems to take care of this parameter when upgrading and inserting data into group_control_map. So I'm wondering whether this bug is invalid, or if checksetup.pl does the migration to group_control_map incorrectly. joel?

Comment 3

[Dave Miller [:justdave]]

If this bug is real, this is a Big Deal, especially since we plan to stop supporting 2.16 soon, we need to remove barriers to upgrading from it.

Comment 4

[Joel Peshkin]

We will have to go back and look carefully at the way 2.16 handled usebuggroupsentry as it was not entirely consistent.  When we originally did this for 2.18, there were a lot of special-cases based on botht he group_control_map AND the parameters.

Comment 5

[Max Kanat-Alexander]

I would tend to agree with comment 2, and think that checksetup.pl is supposed to handle this parameter. If you upgraded Bugzilla without keeping the params around, then you wouldn't migrate properly.

I would tend to suspect that that's what the reporter ran into, and there's not much we can do about that, in this case, except to advise people to upgrade with their params in place.

I think that somebody should at least attempt to reproduce this before we stop our very-near release on this.

Comment 6

[Frédéric Buclin]

I upgraded my two 2.16.10 installations to 2.18.4 and 2.20 respectively, and everything worked as expected in both cases. Bugs which were in groups remain in these groups, user privs remain unchanged and products "protected" by a group remain invisible in enter_bug.cgi, and hacking the URL still prevents me from accessing the product, as expected.

In query.cgi, only "public" products are shown, but selecting none allows you to see all public bugs belonging to all products, including those products you are not allowed to enter bugs into. But this behavior is so by design and was the same in 2.16.10. In other words, no confidential data has been exposed while upgrading.

Marking WFM and removing blocking flags.