Closed Bug 253088 Opened 20 years ago Closed 19 years ago

Users with bless permission cannot edit users

Categories

(Bugzilla :: Administration, task, P2)

2.19
task

Tracking

()

RESOLVED FIXED
Bugzilla 2.16

People

(Reporter: bugreport, Assigned: bugreport)

References

Details

(Whiteboard: [ready for 2.16.8] [fixed in 2.18rc2] [fixed in 2.19.1])

Attachments

(1 file, 1 obsolete file)

When a user with bless permission but not editusers attempts to update a user,
the form variable "user" is not set.  As a result, the balance of editusers.cgi
assumes that the login_name is being changed to a blank.
Status: NEW → ASSIGNED
Flags: blocking2.18?
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18
Attachment #154353 - Flags: review?
Comment on attachment 154353 [details] [diff] [review]
Patch - dont wipe out user if it is not in form

actually, there is a better way
Attachment #154353 - Attachment is obsolete: true
Attachment #154353 - Flags: review?
Attachment #154354 - Attachment description: patch - hide fields instead of skiping them → patch - hide fields instead of skipping them
Attachment #154354 - Flags: review?
The only difference between the two methods is that the first one is safer -- in
the obscure contrived and utterly impractical case that the user is using an
"independent" browser to access the page he may "forget" to supply the user and
then looses data.

I don't care either way, but if you go with the first approach, be sure to do
that ||=ing only if the user doesn't have editusers -- or you'll make it
impossible for an edituser-capable user to erase the name (hmm, but is that
something you want to let them do?)

Your second solution is nice because it also protects the user from erasing
description, which also uses EmitElement. 

Apply r=kiko to the patch you decide to apply, and request a2.18 as well.
Assignee: justdave → bugreport
Status: ASSIGNED → NEW
Attachment #154354 - Flags: review? → review+
Talked over IRC, Joel thinks the latter is the cleaner way.
Flags: approval?
Flags: approval2.18?
Status: NEW → ASSIGNED
Flags: blocking2.18?
Flags: blocking2.18+
Flags: approval?
Flags: approval2.18?
Flags: approval2.18+
Flags: approval+
checked in on both branches.

Note:  This should get seriously cleaned up when this is templatized
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 266333 has been marked as a duplicate of this bug. ***
This problem also exists in 2.16, we need this backported to the 2.16 branch. 
See bug 266333.
Status: RESOLVED → REOPENED
Flags: blocking2.16.8+
Resolution: FIXED → ---
Whiteboard: [wanted for 2.16.8] [fixed in 2.18rc2] [fixed in 2.19.1]
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Wow, believe it or not, this patch applies unmodified to Bugzilla 2.16.7. :)

Bob, care to give it a shot and let us know if it works for you?
I can confirm that the one-liner patch works in the 2.16.7 install.
Actually, I wrote that exact line, patch unseen, and was switching the hash
comment character back and forth between the lines to write out the behavior for
the bug report. Guess I should have used the time to look harder for the bug so
I wouldn't duplicate it. My bad. Good shot, all of you, and quick turnaround.
Thanks.
Status: REOPENED → ASSIGNED
Flags: approval2.16?
Flags: approval2.16? → approval2.16+
Whiteboard: [wanted for 2.16.8] [fixed in 2.18rc2] [fixed in 2.19.1] → [ready for 2.16.8] [fixed in 2.18rc2] [fixed in 2.19.1]

Checking in editusers.cgi;
/cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v  <--  editusers.cgi
new revision: 1.35.2.6; previous revision: 1.35.2.5
done

Checked in on 2.16 branch
Status: ASSIGNED → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.