Created attachment 1102196 [details] snpshot Description of problem: When a request(provisioned by non admin user) detail page is viewed as admin user all the menu headers are not displayed. Version-Release number of selected component (if applicable): 5.5.0.13.20151201120956_653c0d4 How reproducible: 100% Steps to Reproduce: 1.create a user base of approve role 2 login and provision a VM with the above created user 3.Now login as admin and navigate to services->request and click that request 4.check the menu header tabs Actual results: only those tabs are displayed which the role have access too when clicked in request detail page provision by that user. see attached screenshot. ex Automate ,containers missing Expected results: When request details page is viewed as admin user all the menu headers should be displayed Additional info:
Milan, Let me know if you need help with this one. Thanks, ~Harpreet
I'm confirming validity of this bug report. What happens here is that first a non-admin user (who cannot see the whole UI) creates a provisioning request. Then, when admin user (who supposedly should see the whole UI) clicks on that same provisioning request, much of his UI disappears, since User.current_user.current_group gets set to the group of the user who created the provisioning request (i.e. the admin user see just the same portion of UI as the requester). In app/controllers/application_controller/miq_request_methods.rb in prov_set_show_vars() we do: options[:wf] = @miq_request.workflow_class.new(@options, current_user) which goes all the way down to app/models/miq_request_workflow.rb and instance_var_init(): @requester.miq_group_description = values[:requester_group] since we passed admin user as requester, its group here gets changed to the group of the user who made the provisioning request. I'm not entirely sure if this is a problem in the controller in the way we instantiate the workflow object or in the model alone. Keenan, could you please chime in on this? Thanks.
It was tricky to understand the nuances around the current user's group. For tenancy we needed these walls to be more explicit and for there to be no shades of gray. We also needed to know exactly who was performing the request and in what capacity. (they can choose different groups from the upper right hand corner) I'm feeling like there are a number of possible solutions here. Having trouble understanding the implications here. 1. Do we want to `@requester = User.current_user.clone`? global User.current_user will not get corrupted. 2. Do we want requester to be `current_user` or request.requestor? @gmcullough - do you have thoughts on this?
This issue not reproducible with the new menu. Verified: 5.6.0.4-beta2.3.20160421172650_719e256
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/RHBA-2016:1348