312899 - Check if the group resctriction combination is redundant by group inheritance

Status: NEW

(Bugzilla :: Creating/Changing Bugs, enhancement)

Description

[Gabriel Sales de Oliveira]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050725 Firefox/1.0.6 (Ubuntu package 1.0.6)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050725 Firefox/1.0.6 (Ubuntu package 1.0.6)

When restrict a bug to groups if the select combination contains groups with
inheritance show an error to select only one of them.

For example if members of group A are member of group B by inheritance
the group select A + B is redundant.

Reproducible: Always

Comment 1

[Frédéric Buclin]

Not sure I have understood what the problem is.

Comment 2

[Gabriel Sales de Oliveira]

Well, let me explain better:

I have a product with 3 groups:

-Customers

-Developers - wich is member of Customers by inheritance

-Security - wich is member of Customers and Developers the same way

When i edit a bug in this product i'm able to restrict him to a combination of
those groups in all possible ways, but some of my choices are redundant.

For example in this case 4 options are not redundant:

Only Customers - wich grant access to the members of all the 3 groups

Only Developers - wich grant access to the members of Developers and Security

Only Securitys - wich restrict the bug to securitys people 

And None Group - wich turn the bug Public

Today members are able to make a combination like 

Customers - Developers - Security
Customers - Developer

The both are redundant cause by inheritance select to restrict only to Customers 
cause the same result.

The Same happen with the combination:

Developers - Security

I'm doing a sub that, given product groups and 2 groups of the selected
combination, return if the choose is redundant by inheritance and instead of
process the bug force the user to chose only one of those groups.

I believe this clearly the way to restrict bugs to groups that have inheritance...  

Comment 3

[Gabriel Sales de Oliveira]

Attachment: v1-propose

That's what i'm talking about... :\

Comment 4

[Joel Peshkin]

The checks are useful.  There may be a debate about how to use them.

Comment 5

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 6

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.