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

1. 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

1. 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

1. 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

1. 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.