Open Bug 467713 Opened 16 years ago Updated 14 years ago

Allow way of restricting which users show up in the Assign To and QA Contact lists

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: kainhart, Unassigned)

References

(Depends on 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)
Build Identifier: Bugzilla 3.2

In our use of Bugzilla it becomes unnecessarily difficult to sort through the 50+ names that show up in the Assign To and QA Contact lists when changing them when in reality the build of our users are Technical Support personnel who shouldn't even be able to be chosen in this capacity in the first place.

What I think would be simple is if part of User administration allowed an administrator to check a box for each user determines whether they are allowed to have bugs assigned to them or to be chosen as for QA.

Allowing this to be driven of of groups would be great as well since the developers who bugs should be able to be assigned to generally differs from product to product. This being said, having a blanket mechanism to allow or disallow users to be included in these lists globally would be better than nothing.

Reproducible: Always
Summary: Allow some way of restricting which users can show up in the Assign To and QA Contact lists → Allow way of restricting which users show up in the Assign To and QA Contact lists
Similar bug (though not a dupe): bug 372720.

Workaround: turn off the usemenuforusers parameter (which is what we do on all large installations).
You can also use the visibility groups, that's what they're for.
Depends on: 465844
Ok, I've looked into visibility groups but from what I can understand it won't provide the functionality that I'm looking for. How I understand Visibility groups is that they can help to limit how many users are visible in an scenario to another given user. 

The problem here is that if you have 50 developers and 50 QA personnel and 20 from each group are currently visible to a given user, under QA Contact during bug entry you would still see the 20 QA people plus the necessary 20 developers in the list. What I'm looking to do is utilize the combo box look-ups since they are a must for our installation, but to also prevent users from assigning developers as the QA contact and assigning the work for a bug to be done by a QA person. 

My personal preference would be to have a flexible way of categorizing bugs into types (ex. SOFTWARE-DEFECT, WORK-ITEM, DOCUMENTATION-BUT...) and then have different users able to be assigned to bugs depending on the type and the current status. For example a software defect that has been resolved should then be able to be assigned in some way to a particular QA person but not until it is resolved. Now I know type of functioning pretty far outside the scope of how Bugzilla was designed but it was useful to have this type of functionality in Product Studio which is a bug tracking system home grown by Microsoft.

Since the above mentioned change is probably outside of the scope of the this feature request, I would be happy with any type of progress in this direction such as a way of assigning a particular group to a product in separate capacities such as ABLE TO BE QA CONTACT, ABLE TO BE ASSIGNEE. Some consideration should also be given to cases where a customer list is made available as a custom field because the same level of control would likely be desired in those cases as well.
Version: unspecified → 3.2
BTW, it appears my idea of only allowing QA contact to be set when a bug is resolved has been raised as bug#260833.

Some other related bugs are: bug#93367, bug#112319, bug#323870, bug#287333, bug#287332.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Keywords: arch, helpwanted, perf
Another related bug bug#49808.
Keywords: ue
Please don't use these keywords as half of them aren't use by the Bugzilla team, and the other half is irrelevant here.
Keywords: arch, helpwanted, perf, ue
You need to log in before you can comment on or make changes to this bug.