Bug 1489367
| Summary: | [Hammer] Org Admin user cannot create user though cli | |||
|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Jitendra Yejare <jyejare> | |
| Component: | Organizations and Locations | Assignee: | Marek Hulan <mhulan> | |
| Status: | CLOSED ERRATA | QA Contact: | Corey Welton <cwelton> | |
| Severity: | high | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 6.3.0 | CC: | akofink, bbuckingham, cwelton, dhlavacd, dlobatog, egolov, mhulan | |
| Target Milestone: | Unspecified | Keywords: | Triaged | |
| Target Release: | Unused | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1502725 (view as bug list) | Environment: | ||
| Last Closed: | 2018-02-21 17:31:06 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: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1373844 | |||
|
Description
Jitendra Yejare
2017-09-07 09:34:10 UTC
I'll try to reproduce. From quick read I think only the last command should succeed. New user must have orgs and locs set. I am able to reproduce. So, I guess the real question is, should the 'Organization admin' role contain the 'assign_organizations' permission? I don't think org admin should has such permission. The use case is that we have a user who is "org admin of $org", the $org should be auto-assigned to the resource. I think UI does it automatically, API needs to start doing it too. I'll try to look at it this week but I'm offline next week. If you want to look at that, just please ping me and retake :-) This is another org and locs issue, this time for the whole API. No API call sets current organization or location. The reason was that hammer did not support sessions and there's no generic API parameter to set it. One part of the solution is to take the set_taxonomy before filter from UI application controller and put it into application_shared concern. That should ensure that for non-admin user, first available taxonoy is selected. Second part is calling set_user_taxonomies from UserMixin after api login happens in order for user to be able to modify in which context he or she works. Otherwise it would always select the first one. Later I could imagine adding --current-organization override argument but that wuld require more changes. Created redmine issue http://projects.theforeman.org/issues/21119 from this bug Upstream bug assigned to mhulan Upstream bug assigned to mhulan Verified in snap 21 [root@yttrium ~]# hammer user create --auth-source-id 1 --login permutation1 --mail use.r3 --password passwd User [permutation1] created [root@yttrium ~]# hammer user create --auth-source-id 1 --login permutation2 --mail use.r3 --password passwd --organization-ids 1 User [permutation2] created [root@yttrium ~]# hammer user create --auth-source-id 1 --login permutation3 --mail use.r3 --password passwd --location-ids 2 User [permutation3] created [root@yttrium ~]# hammer user create --auth-source-id 1 --login permutation4 --mail use.r3 --password passwd --location-ids 2 --organization-ids 1 User [permutation4] created Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336 |