Check if the group resctriction combination is redundant by group inheritance




13 years ago
9 years ago


(Reporter: gabriel.sales, Unassigned)




(1 attachment)



13 years ago
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

13 years ago
Not sure I have understood what the problem is.

Comment 2

13 years ago
Well, let me explain better:

I have a product with 3 groups:


-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

13 years ago
Created attachment 200105 [details] [diff] [review]

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

Comment 4

13 years ago
The checks are useful.  There may be a debate about how to use them.
Ever confirmed: true


13 years ago
Assignee: create-and-change → gabriel
Severity: normal → enhancement
Target Milestone: --- → Bugzilla 2.24

Comment 5

12 years ago
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".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

Comment 6

11 years ago
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.
Target Milestone: Bugzilla 3.2 → ---


9 years ago
Assignee: gabriel.sales → create-and-change
You need to log in before you can comment on or make changes to this bug.