Bug #21119
[Hammer] Org Admin user cannot create user though cli
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1489367
Description of problem:
An Org Admin user cannot create another user through hammer CLI, throws exception-
"Organization ids Invalid organizations selection, you must select at least one of yours"
Version-Release number of selected component (if applicable):
Satellite 6.3.0 snap 14 / Foreman nighty
How reproducible:
Always
Steps to Reproduce:
1. Create Org Admin role and assign any taxonomies to it
2. Create user and assign above Org Admin role to it and same taxonomies
3. Login with above Org Admin user
4. Attempt to create new users
Actual Results:
Try any of the following
- hammer user create --auth-source-id 1 --login user3_from1 --mail use.r3@gmail.com --password passwd
-> Organization ids Invalid organizations selection, you must select at least one of yours
Location ids Invalid locations selection, you must select at least one of yours
- hammer user create --auth-source-id 1 --login user3_from1 --mail use.r3@gmail.com --password passwd --organization-ids 1
Could not create the user:
Organization ids Invalid organizations selection, you must select at least one of yours
Location ids Invalid locations selection, you must select at least one of yours
- hammer user create --auth-source-id 1 --login user3_from1 --mail use.r3@gmail.com --password passwd --location-ids 2
Could not create the user:
Organization ids Invalid organizations selection, you must select at least one of yours
- hammer user create --auth-source-id 1 --login user3_from1 --mail use.r3@gmail.com --password passwd --location-ids 2 --organization-ids 1
Could not create the user:
Organization ids Invalid organizations selection, you must select at least one of yours
Expected results:
User should be created through Org Admin user
Additional info:
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 User#set_current_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.
Related issues
Associated revisions
History
#1
Updated by The Foreman Bot almost 5 years ago
- Status changed from New to Ready For Testing
- Assignee set to Marek Hulán
- Pull request https://github.com/theforeman/foreman/pull/4878 added
#2
Updated by Marek Hulán over 4 years ago
- Related to Bug #21357: Change the way how default taxonomy is derived added
#3
Updated by Marek Hulán over 4 years ago
- Related to Bug #21343: Organization admin should he able to work with full multitenancy added
#4
Updated by Marek Hulán over 4 years ago
- Related to Bug #21367: Change the way how default taxonomy is derived added
#5
Updated by Marek Hulán over 4 years ago
- Legacy Backlogs Release (now unused) set to 296
- Subject changed from [Hammer] Org Admin user cannot create user though cli to [Hammer] Org Admin user cannot create user though cli
#6
Updated by Anonymous over 4 years ago
- % Done changed from 0 to 100
- Status changed from Ready For Testing to Closed
Applied in changeset f17c9611cb16f949fb178fe3de2aabd231e0de5b.
Fixes #21119 - set taxonomies in API
With this we correctly set the default taxonomy for non-admin users
in API calls. Admins are not touched at all, their context remains
"any context" for API calls. This also refactors various places
where tried to set the right taxonomy and combines them into single
one. This makes API requests work for org admins with single org.
As long as they don't specify any --organization-id(s) or
--location-id(s) parameters, the resource can be created in users'
default organization and location. This is as consistent with UI
as possible and rely on the same bug present in Taxonomix
in combination with DirtyAssociations.