Red Hat Bugzilla – Bug 1288461
Menu header tabs missing when clicked on VM request detail page provisioned by a non-admin user
Last modified: 2016-06-29 11:17:31 EDT
Created attachment 1102196 [details]
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):
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
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
When request details page is viewed as admin user all the menu headers should be displayed
Let me know if you need help with this one.
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 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
@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?
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.
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.