Bug 1462388 - [Bug] Creating Host Group using non-admin user with custom defined role do nothing/greyed out
Summary: [Bug] Creating Host Group using non-admin user with custom defined role do no...
Keywords:
Status: CLOSED DUPLICATE of bug 1464137
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Users & Roles
Version: Unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-17 00:33 UTC by jalviso
Modified: 2021-06-10 12:27 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-30 14:00:28 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description jalviso 2017-06-17 00:33:13 UTC
Description of problem:
Creating Host Group using non-admin user with custom defined role, do nothing/greyed out. 

Version-Release number of selected component (if applicable):
6.2+ up to 6.2.9


How reproducible:


Steps to Reproduce:
1. Create the user with Location/Organization
2. Add the custom role with added filter/permission, search o Host Group as:

Host Group 	edit_hostgroups, destroy_hostgroups, create_hostgroups, view_hostgroups   name ~ org*
Location 	view_locations

3. Create a Host Group

Actual results:

It does nothing. Tail of production log shows:

2017-06-08 17:15:06 b7285435 [app] [I] Started POST "/hostgroups" for 10.64.0.215 at 2017-06-08 17:15:06 +1000
2017-06-08 17:15:06 b7285435 [app] [I] Processing by HostgroupsController#create as */*
2017-06-08 17:15:06 b7285435 [app] [I]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"8mp1cIDFW4wvkMTnglA/E32LrveoRlI7NtCD63Shx5o=", "hostgroup"=>{"parent_id"=>"", "name"=>"ossj", "lifecycle_environment_id"=>"1", "content_view_id"=>"9", "environment_id"=>"3", "content_source_id"=>"1", "puppet_ca_proxy_id"=>"1", "puppet_proxy_id"=>"1", "openscap_proxy_id"=>"", "puppetclass_ids"=>[""], "domain_id"=>"", "realm_id"=>"", "architecture_id"=>"1", "operatingsystem_id"=>"2", "ptable_id"=>"61", "root_pass"=>"[FILTERED]", "location_ids"=>["2", ""], "id"=>""}, "kt_activation_keys"=>""}
2017-06-08 17:15:06 b7285435 [app] [D] Setting current user thread-local variable to testuser
2017-06-08 17:15:06 b7285435 [app] [D] Setting current organization thread-local variable to gss
2017-06-08 17:15:06 b7285435 [app] [D] Setting current location thread-local variable to bne
2017-06-08 17:15:06 b7285435 [app] [I] Failed to save: Location ids Invalid locations selection, you must select at least one of yours   <===========
2017-06-08 17:15:06 b7285435 [app] [I]   Rendered puppetclasses/_classes.html.erb (6.4ms)
2017-06-08 17:15:06 b7285435 [app] [I]   Rendered puppetclasses/_class_selection.html.erb (31.5ms)

Expected results:

It should at least gives an error message that something is missing.

Additional info:

The Host Group was created when adding "assign_locations":

Location:  	assign_locations, view_locations

The user has already Location/Organization assigned, but it seems like the Location define in Roles specifically ask to assign Location again. Is this expected behaviour?

Comment 2 Marek Hulan 2017-06-30 14:00:28 UTC
Yes, this is intended behavior. Users must be assigned to organization/location so they can work with it (select it in top left corner, see it's resources). The view_organizations and view_locations is also required if users want to list existing orgs/locs in Administer menu. The assign_organizations and assign_locations are used when user tries to create/update some resource, e.g. subnet. The form contains tabs "Locations" and "Organizations", users can see only those that they have assign permission for. The reason is that by assigning the organization/location to the resource, you're not just updating the resource but the organization/location itself and potentially letting users from the new scope work with the existing resource. Therefore we have extra permission so users can set it very granularly.

I agree the validation message is confusing since it does not mention anything about assign permission. This is being addressed by BZ 1464137, so I'm setting this as a duplicate. Please reopen if something is not clear or I misunderstood the question.

*** This bug has been marked as a duplicate of bug 1464137 ***


Note You need to log in before you can comment on or make changes to this bug.