Currently membership in a group is private. I'd like groups to have the option of being: Secret - what we have today Member - members in the group should be able to find out if another account is in the group Public - anyone can find out that a person is a member of a group -- If a group's membership is set to member and a group's badge setting isn't never, then when a member of a group sees another member of the group, that member should have their badge shown. -- If a group's membership is set to Public, then a user with editusers should be able to select the group from the limit list. If a group's membership is set to Member, then a user with editusers who is a member of the group should be able to select the group from the limit list even if the user doesn't have bless for that group. As with today, if a group's mmebership is set to Private, then only a user with editusers and bless for that group should be able to see the group in the limit option.

I really don't see the interest for this bug. People is complaining that Bugzilla is hard to use, this request make it even worse. Suggesting WONTFIX.

Bug 332473 would be nice, too, but I don't see any reason for this to depend on it. We need this for b.m.o. There's a lot of corporate-confidential stuff starting to show up on bugzilla.mozilla.org because we like to be open by default, so the line between what should be confidential and what shouldn't is pretty gray, and it's nice to be able to flip a bit on a bug to toggle it instead of having to move it to some other Bugzilla. (This makes it easier and more likely for something that was hidden and shouldn't be to get opened up to the public as well) There's also several folks in the community who are not Mozilla employees who help out in running various parts of Bugzilla. We'd be nowhere without volunteers. However, said volunteers need to be able to manage things without the temptation to go look at Mozilla company-confidential stuff that might be in the system. What would ideally work for us is to have editusers privs only extend to editing the actual user account information (name, email, password, disabled, etc), and not allow editing of group membership. Group membership granting would still be controlled by giving them grant rights for groups they need to be able to manage. Full admin privs would be required to be able to edit any group membership on a user.

Then rather than implementing comment 0, you should rather redefine what a user with editusers privs can do. And keep group edition for admins only. This would be much easier to implement.

Yes, I agree. It seems like a logical separation, as you can already individually hand out grant access to all the groups, and if you really want to easily allow someone to edit all of them, just make sure some group they're in is inherited as grant rights to all of the groups when you create them.

This simple patch basically does what comment #3 and comment #4 say. This changes editusers from having bless privileges for all groups by default to only having bless privileges for groups for which the user specifically has bless privilege bits. All other editusers powers are still intact. The only thing I don't like about this is that this restricts the ability for a person with editusers to search for users in groups that are not blessable, but I think that's livable for now (but something to think about for the future). I guess I could add a parameter to bless_groups() to allow for specific exemptions or something, so that I could allow the search box to display all groups.

Update text on permissions page in preferences and update documentation to reflect change in how editusers works.

Comment on attachment 296684 [details] [diff] [review] patch - v2 >Index: Bugzilla/User.pm >- if ($self->in_group('editusers')) { >- # Users having editusers permissions may bless all groups. >+ if ($self->in_group('admin')) { >+ # Users having admin permissions may bless all groups. POD must be fixed accordingly. Moreover, should usevisibilitygroups still be associated with editusers or with admin now? >Index: docs/xml/administration.xml >- If you have <quote>editusers</quote> privileges or if you are allowed >+ If you have <quote>admin</quote> privileges or if you are allowed > to grant privileges for some groups, the <quote>Users</quote> link > appears in the footer. This change is wrong. I will still see the link with editusers privs. Moreover: - docs/xml/using.xml still mentions that (grep for permissionsettings): A complete list of permissions is below. Only users with <emphasis>editusers</emphasis> privileges can change the permissions of other users. This is now wrong as you need admin privs. - editusers.cgi needs a lot of changes. I can easily hack the URL to bypass changes made to the UI. - template/en/default/admin/users/edit.html.tmpl needs to be fixed as well as some UI is based on the test [% IF editusers %]. Some of these tests are still valid, but some others need to be changed.

No new feature accepted for 3.2

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.