430275 - strict_isolation + usemenuforusers not restricting user lists to users with edit privs only

Status: NEW

(Bugzilla :: Creating/Changing Bugs, defect, P2)

Description

[Neil Aggarwal]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Build Identifier: Version 3.0.3

I have strict_isolation set On and usemenuforusers set to On.

For each of my products, I set up a group for that product with Mandatory/Mandatory, ENTRY, CANEDIT controls.

When I login as a user for a product and bring up a bug, the CC list shows all the users on the system, incluging users from other projects.

Also, the "reassign bug to" listing is also showing all users that are on the system.

This is not good for a couple of reasons:
1. There are users that are not relevant to a product so the CC and reassign lists are unneccessarily cluttered.
2. Users can see everyone on the system.  I would only like them to see who is relevant to their product.


Reproducible: Always

Steps to Reproduce:
1. Create two products
2. Create a group for each product and set the permissions to Mandatory/Mandatory, ENTRY, CANEDIT
3. Create at least one user in each group
4. Login with a user and file a bug
5. Go to the bug detail page and you can see users from the other group in the CC and reassign list.
Actual Results:  
I can see all users in the CC and reassign list.

Expected Results:  
Only show users allowed to access the project.

Comment 1

[Frédéric Buclin]

Some users are listed despite they cannot be added to the bug because they don't belong to groups which have the CANEDIT bit set, which is very confusing. The list should indeed be restricted to users who can be added to the bug.

Note that this bug is a UI bug only. process_bug.cgi will correctly catch unwanted users and throw an error. Anyway, marking as blocker for 3.2 as the confusion is pretty high. I had to read the source code to check if users are correctly filtered by process_bug.cgi/Bug.pm when strict_isolation is enabled. We can take the fix for 3.0.x as well, but we won't block 3.0.4 on it.

Comment 2

[Frédéric Buclin]

Note: to fix this bug, we have to edit User::get_userlist() so that it excludes users who cannot edit the product the bug is in. One slow way to do this is to call Bugzilla::User->new()->can_edit_product($prod_id) for each user. $prod_id should be passed to get_userlist() to restrict the list. If undefined, return the same list as it does currently.

Comment 3

[Frédéric Buclin]

I see no good way to fix this bug besides what I suggested in comment 2. I will let someone else with a more efficient way fix this bug.

Comment 4

[Max Kanat-Alexander]

In that case, I don't think this is serious enough to block 3.2. It's been hanging around in 3.0 for a while now, and it hasn't killed anybody.

I think we'll need some re-architecture of things to make this easier to fix.

Comment 5

[Andrew Goldman]

I also ran into this problem in BugZilla 3.4.1 and was able to do a quick modification as follows (very much related to comment #2):

In User.pm, after 

    while (my($login, $name, $visible) = $sth->fetchrow_array) {

add

        my $test = new Bugzilla::User(login_to_id($login));

to generate the user object.  Then to include it in the userlist array, add:

            self => $test

below

            visible => $visible,

Next, in the global folder where the userlist is generated whenever populating the Assign To or CC List, edit userselect.html.tmpl and add the following check before the option values are created

     	[% IF selectedproduct.user_has_access(tmpuser.self) == 1 %]

Please note though that you also must edit create.html.tmpl and pass the current product as selectedproduct to userselect.html.tmpl

Works like a charm!

Comment 6

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).