Bug 1288461 - Menu header tabs missing when clicked on VM request detail page provisioned by a non-admin user
Menu header tabs missing when clicked on VM request detail page provisioned b...
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS (Show other bugs)
5.5.0
Unspecified Unspecified
high Severity medium
: GA
: 5.6.0
Assigned To: Milan Zázrivec
Aziza Karol
ui:rbac
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-04 05:13 EST by Aziza Karol
Modified: 2016-06-29 11:17 EDT (History)
8 users (show)

See Also:
Fixed In Version: 5.6.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-29 11:17:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
snpshot (66.75 KB, image/png)
2015-12-04 05:13 EST, Aziza Karol
no flags Details

  None (edit)
Description Aziza Karol 2015-12-04 05:13:56 EST
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:
Comment 2 Harpreet Kataria 2016-01-13 12:31:39 EST
Milan,

Let me know if you need help with this one.

Thanks,
~Harpreet
Comment 3 Milan Zázrivec 2016-01-18 12:20:06 EST
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.
Comment 4 Keenan Brock 2016-01-25 09:27:49 EST
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?
Comment 5 Aziza Karol 2016-04-25 07:12:01 EDT
This issue not reproducible with the new menu.

Verified: 5.6.0.4-beta2.3.20160421172650_719e256
Comment 7 errata-xmlrpc 2016-06-29 11:17:31 EDT
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

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