Closed
Bug 303784
Opened 19 years ago
Closed 19 years ago
Visibility can keep admin from administering groups
Categories
(Bugzilla :: Administration, task, P2)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.20
People
(Reporter: bugreport, Assigned: bugreport)
Details
Attachments
(2 files, 3 obsolete files)
|
3.14 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
|
3.21 KB,
patch
|
LpSolit
:
review+
|
Details | Diff | Splinter Review |
Either editusers or admin should override group and user visibility on all admin pages. Currently, it is possible for an admin to make groups invisible to himself. I do not see any reason this should apply to non-administrative pages. There is some benefit in permitting an admin to exclude himself from sections of the system to avoid clutter.
| Assignee | ||
Updated•19 years ago
|
Assignee: administration → bugreport
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.22
| Assignee | ||
Comment 1•19 years ago
|
||
A user with editusers can always promote himself anyway. Don't stand in the way of that user administering groups. Users with editusers are NOT forced to see every group when not acting in an administrative capacity. Note: Users who have bless permissions but no editusers membership are still more restricted.
| Assignee | ||
Updated•19 years ago
|
Attachment #192274 -
Flags: review?
Comment 2•19 years ago
|
||
If a site wants to give visibility on a group (all groups) to editusers people, they can give the editusers group visibility to it (them). If a site wants to give full user visibility to editusers people, they can introduce an everybody group with .* regexp and give the editusers group visibility to it. Why should we effectively force every site do this?
| Assignee | ||
Comment 3•19 years ago
|
||
Tried that.... it's pretty clunky. Why would we want to prevent someone with editusers privileges from doing this? There is nothing else a user with editusers cannot do.
Comment 4•19 years ago
|
||
Comment on attachment 192274 [details] [diff] [review] Patch - have editusers.cgi let users with editusers see any user and every group groupsUserMayBless() no longer exists, see bug 284263
Attachment #192274 -
Flags: review? → review-
| Assignee | ||
Updated•19 years ago
|
Severity: normal → major
Flags: blocking2.20.1?
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
| Assignee | ||
Comment 5•19 years ago
|
||
Attachment #192274 -
Attachment is obsolete: true
Attachment #196321 -
Flags: review?(LpSolit)
| Assignee | ||
Updated•19 years ago
|
Flags: blocking2.20.1? → blocking2.20?
Comment 6•19 years ago
|
||
Comment on attachment 196321 [details] [diff] [review] v2 - unrotted The patch allows me to see all groups/users when I have editusers privs, but I cannot edit any user account I'm not already allowed to edit, due to User::can_see_user() which prevents me to access that account. As can_see_user() is only used in editusers.cgi, I think it's safe to modify it too in order to take Param('editusers') into account.
Attachment #196321 -
Flags: review?(LpSolit) → review-
| Assignee | ||
Comment 8•19 years ago
|
||
This patch keeps getting bigger. There are several places where I removed checks for csn_see_user since the check immediately prior to it checked for editusers privileges altogether.
Attachment #196321 -
Attachment is obsolete: true
Attachment #197235 -
Flags: review?(LpSolit)
Updated•19 years ago
|
Flags: blocking2.20? → blocking2.20.1+
Comment 9•19 years ago
|
||
Comment on attachment 197235 [details] [diff] [review] v3 - cover the rest of user editing as well >Index: editusers.cgi >+ if (!$editusers && (Param('usevisibilitygroups'))) { Nit: why are you using so many parens (around Param())? >+ $user->can_see_user($otherUser) || $editusers Nit: I would prefer to check for $editusers first. If the user is in the 'editusers' group, we avoid a useless SQL call. >+ $user->can_see_user($otherUser) || $editusers Same remark here. >Index: Bugzilla/User.pm >+ if ((!$self->in_group('editusers')) && (Param('usevisibilitygroups'))) { Nit: again, why so many parens?? Please fix the nits about checking $editusers first and carry forward my r+. r=LpSolit for the tip only (the patch doesn't apply cleanly on 2.20).
Attachment #197235 -
Flags: review?(LpSolit) → review+
| Assignee | ||
Updated•19 years ago
|
Flags: approval?
Flags: approval2.20?
Comment 10•19 years ago
|
||
As I said, I would like an updated patch with my nit fixed + a backport for 2.20.
Flags: approval?
Flags: approval2.20?
| Assignee | ||
Comment 11•19 years ago
|
||
Attachment #197235 -
Attachment is obsolete: true
Attachment #197312 -
Flags: review?(LpSolit)
Comment 13•19 years ago
|
||
Comment on attachment 197312 [details] [diff] [review] v4 for HEAD with nits fixed r=LpSolit
Attachment #197312 -
Flags: review?(LpSolit) → review+
Comment 14•19 years ago
|
||
Comment on attachment 197314 [details] [diff] [review] patch for 2.20 r=LpSolit
Attachment #197314 -
Flags: review?(LpSolit) → review+
Updated•19 years ago
|
Status: NEW → ASSIGNED
Flags: approval?
Flags: approval2.20?
Updated•19 years ago
|
Flags: approval?
Flags: approval2.20?
Flags: approval2.20+
Flags: approval+
Comment 15•19 years ago
|
||
tip: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.105; previous revision: 1.104 done Checking in Bugzilla/User.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v <-- User.pm new revision: 1.82; previous revision: 1.81 done 2.20rc2: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.90.2.6; previous revision: 1.90.2.5 done Checking in Bugzilla/User.pm; /cvsroot/mozilla/webtools/bugzilla/Bugzilla/User.pm,v <-- User.pm new revision: 1.61.2.8; previous revision: 1.61.2.7 done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•