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
Not sure I have understood what the problem is.
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...
The checks are useful. There may be a debate about how to use them.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: create-and-change → gabriel
Severity: normal → enhancement
Target Milestone: --- → Bugzilla 2.24
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
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 → ---
You need to log in before you can comment on or make changes to this bug.