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:
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.
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.
This does not block any RFE, removing the artificial relationship.
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
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.
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.
Moving to virt for further testing. I suggest also to move to 3.6.6.
can you please update whether it works after upgrading your client?
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.
It has been fixed in 3.6.5, the problem was the incorrect version of remote-viewer, closing