Bug 1005044

Summary: User.update should allow adding members to a group by a group member which has bless privilege on that group
Product: [Community] Bugzilla Reporter: Muhammad Tahir <mtahir>
Component: WebServiceAssignee: Matt Tyson 🤬 <mtyson>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.4CC: cnicolai, huiwang, jmcdonal, kfenzi, mtahir, mtyson, pingou, qgong, rjoost
Target Milestone: 4.4   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.4.11046.4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-25 04:45:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Muhammad Tahir 2013-09-06 06:12:31 UTC
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-10 02:04:40 UTC
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 04:46:44 UTC
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 05:44:24 UTC
The first upstrema bug has been resolved. The second is still open.

Comment 5 Simon Green 2014-06-22 21:04:19 UTC
(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 21:10:44 UTC
Re-targeting. I have no desire to back port this to create more pain for our team.

Comment 9 Muhammad Tahir 2015-11-20 05:24:39 UTC
*** Bug 1283831 has been marked as a duplicate of this bug. ***

Comment 10 Jason McDonald 2015-11-20 05:32:10 UTC
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-05 03:07:09 UTC
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 05:35:29 UTC
(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-11 02:59:31 UTC
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-12 03:40:03 UTC
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','Bugzilla_password':'xxx','names':['sophia2'],  'groups':{'set':['redhat']}})
{'users': [{'changes': {'groups': {'removed': '', 'added': 'redhat'}}, 'id': 388172}]}

Comment 16 Matt Tyson 🤬 2016-01-25 04:45:57 UTC
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.