Bug 1304755 - admin should have permission to see 'change CD' in admin portal
admin should have permission to see 'change CD' in admin portal
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
3.6.3
Unspecified Unspecified
high Severity medium (vote)
: ovirt-3.6.6
: ---
Assigned To: Tomas Jelinek
Shira Maximov
:
Depends On: 1325833
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-04 09:29 EST by Shira Maximov
Modified: 2016-04-26 02:33 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-26 02:33:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mgoldboi: ovirt‑3.6.z?
mgoldboi: planning_ack+
oourfali: devel_ack+
mshira: testing_ack?


Attachments (Terms of Use)
Debug of not working vv file (3.16 KB, text/plain)
2016-03-31 12:00 EDT, Shira Maximov
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 53136 master MERGED webadmin,userportal: Pass isAdmin flag to UI 2016-02-15 09:34 EST
oVirt gerrit 53530 ovirt-engine-3.6 MERGED webadmin,userportal: Pass isAdmin flag to UI 2016-02-15 11:01 EST

  None (edit)
Description Shira Maximov 2016-02-04 09:29:04 EST
Description of problem:
the admin should have permission to see the 'change CD' in the admin portal,
should be  admin=1 and not  admin=0.

Version-Release number of selected component (if applicable):
 Red Hat Enterprise Virtualization Manager Version: 3.6.3-0.1.el6 

How reproducible:
100%

Steps to Reproduce:
1. create a vm 
2.open console - if the 'change CD' is not available is because there is no permission for the admin
3.

Actual results:


Expected results:


Additional info:
Comment 1 vszocs 2016-02-05 09:14:12 EST
This is a bug where UI doesn't receive proper user info, which results in passing `admin=0` within console.vv file, regardless if the user is an admin or not.
Comment 2 Red Hat Bugzilla Rules Engine 2016-02-06 09:11:05 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 4 Yaniv Kaul 2016-02-25 07:03:58 EST
This does not block any RFE, removing the artificial relationship.
Comment 5 Shira Maximov 2016-03-31 12:00 EDT
Created attachment 1142294 [details]
Debug of not working vv file

Failed to verify on :  Red Hat Enterprise Virtualization Manager Version: 3.6.5-0.1.el6 

verification steps:
1. Create a new VM 
2. open VM console- check if change 'CD' tab appears -> The 'Change CD' didn't appear 
3. open the .vv file and check if admin=1 or admin=0 -> admin=1 as expected
4. add permission to admin and check again the 'change CD' tab -> the 'change CD' appears 


I also compared one working and one that not, and the only differences are:
the port number, the password, title, tls-port and vm-guid
Comment 6 Red Hat Bugzilla Rules Engine 2016-04-04 02:17:17 EDT
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 7 vszocs 2016-04-04 09:56:28 EDT
Hm, I don't see any obvious errors in attached log file, seems strange to me.

The UI bug of not having proper `admin` flag in .vv file has been fixed and verified. There must be some other issue.
Comment 8 Oved Ourfali 2016-04-06 06:36:20 EDT
Moving to virt for further testing.
I suggest also to move to 3.6.6.
Comment 9 Michal Skrivanek 2016-04-18 08:12:44 EDT
can you please update whether it works after upgrading your client?
Comment 10 Shira Maximov 2016-04-18 08:31:52 EDT
I upgraded my client to fedora 23, in order to have virt-viewer-3.0-1.fc23.x86_64
and now it's working fine.
you can close this bug.
Comment 11 Tomas Jelinek 2016-04-26 02:33:31 EDT
It has been fixed in 3.6.5, the problem was the incorrect version of remote-viewer, closing

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