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: | WebService | Assignee: | Matt Tyson 🤬 <mtyson> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.4 | CC: | 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
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. Both of those upstream bugs have been open for >4 years, so realistically we'd have to contribute the fixes ourselves. The first upstrema bug has been resolved. The second is still open. (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 Re-targeting. I have no desire to back port this to create more pain for our team. *** Bug 1283831 has been marked as a duplicate of this bug. *** 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. 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? (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. 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. 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}]}
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. |