Bug 1005044 - User.update should allow adding members to a group by a group member which has bless privilege on that group
User.update should allow adding members to a group by a group member which ha...
Status: CLOSED CURRENTRELEASE
Product: Bugzilla
Classification: Community
Component: WebService (Show other bugs)
4.4
Unspecified Unspecified
medium Severity medium (vote)
: ---
: ---
Assigned To: Matt Tyson
tools-bugs
:
: 1283831 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-06 02:12 EDT by Muhammad Tahir
Modified: 2016-01-24 23:45 EST (History)
9 users (show)

See Also:
Fixed In Version: 4.4.11046.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-24 23:45:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 1237161 None None None 2016-01-06 00:55 EST
Mozilla Foundation 442013 None None None Never
Mozilla Foundation 469196 None None None Never

  None (edit)
Description Muhammad Tahir 2013-09-06 02:12:31 EDT
Description of problem:

Users who are not members of the editusers group cannot use User.update to add members to the groups on which they have bless privilege. It throws this error
"Sorry, you aren't a member of the 'editusers' group, and so you are not authorized to add, modify or delete users."

Version-Release number of selected component (if applicable):


How reproducible:
For example: User A can bless group G. Using User.update if user A tries to bless user B with group G, following error message is returned.
"Sorry, you aren't a member of the 'editusers' group, and so you are not authorized to add, modify or delete users."

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Simon Green 2013-09-09 22:04:40 EDT
The ability to change groups in User.update is a Red Hat customisation. While it would be pretty easy to fix this, it should be fixed properly so it can go upstream.

I had a crack at this earlier this year (https://bugzilla.mozilla.org/show_bug.cgi?id=837968), but was review-'ed because the code that sets groups existed in B/WebService/User.pm, and not Bugzilla::User. For the UI, that code is in editusers.cgi.

Therefore is isn't going to be a simple change if we want to do it properly. There are two upstream bugs that must be fixed.
Comment 2 Jason McDonald 2013-09-11 00:46:44 EDT
Both of those upstream bugs have been open for >4 years, so realistically we'd have to contribute the fixes ourselves.
Comment 4 Jason McDonald 2014-06-20 01:44:24 EDT
The first upstrema bug has been resolved. The second is still open.
Comment 5 Simon Green 2014-06-22 17:04:19 EDT
(In reply to Jason McDonald from comment #4)
> The first upstream bug has been resolved. The second is still open.

On to it, I already had done half of the second one (see upstream dup), so it should be pretty quick to knock out. Will be a good one to get sorted before 5.0 is released.

  -- simon
Comment 6 Simon Green 2014-06-22 17:10:44 EDT
Re-targeting. I have no desire to back port this to create more pain for our team.
Comment 9 Muhammad Tahir 2015-11-20 00:24:39 EST
*** Bug 1283831 has been marked as a duplicate of this bug. ***
Comment 10 Jason McDonald 2015-11-20 00:32:10 EST
Can we please get this bug into a 4.4 sprint?  It is blocking the removal of admin rights and access to embargoed bugs for several users who really shouldn't have those capabilities.
Comment 11 Jeff Fearn 2016-01-04 22:07:09 EST
Cherry picking these changes from upstream will break the API for the current customisation, do we want to do this outside a major version change?
Comment 12 Matt Tyson 2016-01-06 00:35:29 EST
(In reply to Jeff Fearn from comment #11)
> Cherry picking these changes from upstream will break the API for the
> current customisation, do we want to do this outside a major version change?

This can be done without breaking API compatibility.  I don't know how upstream intends to solve this though.  I've raised a bug with them, we'll see what solution they prefer.
Comment 14 Matt Tyson 2016-01-10 21:59:31 EST
Pulling this into sprint 46.

Upstream seems to be OK with my proposed solution, so this shouldn't cause us any backwards compatability issues when upstream merges the patch.
Comment 15 Hui Wang 2016-01-11 22:40:03 EST
Verified this issue.
The result is PASS.
Version:rh-bugzilla-4.4.11046-1.el6.noarch
Steps:
1.Create one user with redhat group
2.Create another user with no redhat group
3.The user(sophia1) that is in redhat group adds the user(sophia2) that is not in redhat group to redhat group

>>>proxy.User.update({'Bugzilla_login':'sophia1@redhat.com','Bugzilla_password':'xxx','names':['sophia2@redhat.com'],  'groups':{'set':['redhat']}})
{'users': [{'changes': {'groups': {'removed': '', 'added': 'redhat'}}, 'id': 388172}]}
Comment 16 Matt Tyson 2016-01-24 23:45:57 EST
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.

Note You need to log in before you can comment on or make changes to this bug.