Change editusers to only have bless privileges for groups for which the user has bless privileges

ASSIGNED
Assigned to

Status

()

P3
enhancement
ASSIGNED
13 years ago
5 years ago

People

(Reporter: timeless, Assigned: reed)

Tracking

Dependency tree / graph

Details

(Whiteboard: [wanted-bmo])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Blocks: 332475

Updated

13 years ago
OS: MacOS X → All
Hardware: Macintosh → All
Summary: Group membership visibility should be selectable → Ability to make certain groups not visible to users with editusers

Comment 1

13 years ago
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.
(Reporter)

Updated

12 years ago
No longer blocks: 332475
(Reporter)

Updated

12 years ago
Blocks: 244239
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.
No longer depends on: 332473
Whiteboard: [wanted-bmo]

Comment 3

11 years ago
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.
(Assignee)

Updated

11 years ago
Target Milestone: --- → Bugzilla 3.2
(Assignee)

Comment 5

11 years ago
Created attachment 296682 [details] [diff] [review]
patch - v1

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.
Assignee: user-accounts → reed
Status: NEW → ASSIGNED
Attachment #296682 - Flags: review?(LpSolit)
(Assignee)

Updated

11 years ago
Summary: Ability to make certain groups not visible to users with editusers → Change editusers to only have bless privileges for groups for which the user has bless privileges
(Assignee)

Comment 6

11 years ago
Created attachment 296684 [details] [diff] [review]
patch - v2

Update text on permissions page in preferences and update documentation to reflect change in how editusers works.
Attachment #296682 - Attachment is obsolete: true
Attachment #296682 - Flags: review?(LpSolit)
(Assignee)

Updated

11 years ago
Attachment #296684 - Flags: review?(LpSolit)

Comment 7

11 years ago
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.
Attachment #296684 - Flags: review?(LpSolit) → review-

Updated

11 years ago
Priority: -- → P1

Updated

10 years ago
Priority: P1 → P3

Comment 8

10 years ago
No new feature accepted for 3.2
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0

Comment 9

6 years ago
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.
Target Milestone: Bugzilla 4.4 → ---
You need to log in before you can comment on or make changes to this bug.