Description of problem: Changing the role of user results in removal of its ownership from the hosts. Also not able to edit the organization and location of that user. Version-Release number of selected component (if applicable): 6.0.8 How reproducible: Always Steps to Reproduce: 1. The host profile which was owned by the user. i.e after changing the role of user (in this case site-manager) the additional information tab of host profile reset the 'owned by' field to 'select an owner' but properties page shows the owner as same user. 2. The default assigned organization & location fields of user gets grayed because of point 1 once the role is changed. 3. After re-submitting the 'owned by' value of host profile, the default assigned organization and location gets removed from the user profile and need to re-add them. After re-adding the organization and location to the user profile, the user is again visible under desired organization & location. Also can be set that user as owner to host which owned by it previously. Actual results: 1. User is not listed under respective organization/location. 2. Host ownership gets changed to 'Admin' satellite webui --> Hosts --> All Hosts --> Click on host profile --> Edit --> Additional Information --> 'Owned By' But the value donot change at satellite webui --> Hosts --> All Hosts --> Click on host profile --> Details --> Owner 3. As the user is locked with hosts details page, it not possible to edit it and re-add the organization/location to it. Expected results: After changing the role of user the host ownership still should remain same and the user should be present under the selected organization & location. Additional info:
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Created redmine issue http://projects.theforeman.org/issues/12864 from this bug
Per 6.3 planning, moving out non acked bugs to the backlog
Reproducing steps: 1. create a user not assigned to any org/loc 2. create a host in some org/loc 3. update host owner via hammer (webui would not let you), e.g. hammer host update --owner ares --id a.example.tst Actual results: API lets you assign owner from different or none org/loc. Expected results: API does not allow you to do this (web ui does not expose such users in select box already). Also webui should check parameters in assigning action, see below. Additional info: I tested carefully and it has nothing to do with reassigning role, that seems to work just fine. You can achieve the same bug through webui if you open 2 tabs, in one load the host edit form before you change user orgs/locs, then submit it with old select box. This means we should verify the parameters in assigning action too.
Upstream bug assigned to mhulan
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/12864 has been resolved.
Build: Satellite 6.3.0 snap29 Verification steps: 1) Create a User with no org/loc Id: 6 Login: Ohno Name: Oh no Email: Admin: no Last login: Authorized by: Internal Effective admin: no Locale: default Timezone: Description: Default organization: Default location: Roles: User groups: Inherited User groups: Created at: 2017/12/20 13:27:33 Updated at: 2017/12/20 13:27:33 2) Create a host in some org/loc hammer> host info --id 14 Id: 14 UUID: d2b9aa80-c4de-4bfe-a40d-b6bdb3103a67 Additional info: Owner Id: 3 Owner Type: User Enabled: yes Comment: 3) Try to update ownership Web UI doesn't list the created user in drop down Hammer: hammer> host update --owner Ohno --id 14 Could not update the host: Is owned by does not belong into host's organization Is owned by does not belong into host's location Scenario 2: You can achieve the same bug through webui if you open 2 tabs, in one load the host edit form before you change user orgs/locs, then submit it with old select box. This means we should verify the parameters in assigning action too. Error on UI: does not belong into host's organization and does not belong into host's location
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