Bug 1273025 - User portal's permission tab offers to add permissions which cannot be added
User portal's permission tab offers to add permissions which cannot be added
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.5.4
Unspecified Unspecified
low Severity low
: ovirt-4.0.0-alpha
: 4.0.0
Assigned To: Marek Libra
movciari
:
Depends On:
Blocks: 1213937
  Show dependency treegraph
 
Reported: 2015-10-19 08:20 EDT by Petr Spacek
Modified: 2016-08-23 16:30 EDT (History)
8 users (show)

See Also:
Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Enhancement
Doc Text:
Previously, in the User Portal, all roles were displayed. With this enhancement, only the roles that can be assigned are listed to avoid confusion.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-08-23 16:30:10 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 47779 master MERGED userportal: Only assignable roles shown on VM/Template permission tab Never

  None (edit)
Description Petr Spacek 2015-10-19 08:20:03 EDT
Description of problem:
User portal's permission tab offers to add permissions which cannot be added because user does not have sufficient permissions.

Version-Release number of selected component (if applicable):
3.5.4.2-1.3.el6ev

How reproducible:
100 %

Steps to Reproduce:
1. Log-in as user with PowerUser role on Cluster level.
2. Create a new VM in respective Cluster.
3. On Permissions tab, pick a random user, select SuperUser persmission from drop-down list and click Ok. 

Actual results:
Following error message is shown:
"Error while executing action: Cannot add permission, only system super user can give permissions with admin Role"

Expected results:
SuperUser permissions is not even shown in the drop-down list in User Portal (and is greyed out in Admin Portal so the admin knows that there is something he cannot do).
Comment 1 Einav Cohen 2015-10-20 08:08:14 EDT
for VMs and Templates in the super-user portal: need to filter the Roles list in the Add Permission dialog to contain only User Roles.
Comment 2 Marek Libra 2015-10-29 10:47:23 EDT
From the discussion with Einav: When logged as
- user: just assignable roles will be displayed
- super user or admin: all roles will be displayed without highlighting the admin roles
Comment 3 Petr Spacek 2015-10-29 10:55:51 EDT
Hmm, we should take into account that there are different levels of admins.

E.g. the fact that I'm read-only admin for the whole system and SuperUser for a "cluster1" does not mean that I should see full list of permissions (in add dialog) for "cluster2". Generally I would say that Add button could be even grayed out if there is no possible selection (as in case of "cluter2" in the previous example).
Comment 4 Einav Cohen 2015-10-29 11:10:22 EDT
(In reply to Petr Spacek from comment #3)
> Hmm, we should take into account that there are different levels of admins.
> 
> E.g. the fact that I'm read-only admin for the whole system and SuperUser
> for a "cluster1" does not mean that I should see full list of permissions
> (in add dialog) for "cluster2". Generally I would say that Add button could
> be even grayed out if there is no possible selection (as in case of
> "cluter2" in the previous example).

we are currently not blocking any action in the admin UI based on permissions - preventing performing unauthorized actions is done on the backend level. 

In addition, we are not filtering anything from the view in the admin UI - our assumption is that if you are an admin (even a read-only one), you can *see* everything (it does not mean that you can *do* everything - you will be blocked on the backend level if you attempt to perform an unauthorized action).
Comment 5 Petr Spacek 2015-10-29 11:24:05 EDT
I understand that admin can see everything, but from human's perspective (term incorporating users & admins) it is extremely annoying to spend time filling in forms just to find out that the person does not have sufficient permissions and that all the information filled in are lost, along with time spent on it.

This is particular problem for power users and lower-level admins which can often encounter insufficient permissions by accident. This happens a lot in deployment my team is using because we have plenty of 'power users' which are not cluster admins. Trust me, this makes them very angry. (This is reinforced by fact that RHEV-M web UI is not the fastest one, so users spend more time waiting for application to open forms and clicking around - which costs them some patience - and then boom - they get permissions denied!)

I hope that this clarifies why I believe that it is important to inform users about what they can do as early as possible, so they do not waste their time and nerve.
Comment 6 Marek Libra 2015-10-30 03:38:15 EDT
I'm pushing patch set 3 conforming the Comment 4.

Information needed for Comment 5 can be recently gained from the role naming convention - roles as *Admin or *Manager (plus exceptions MacPoolUser and vmImporterExporter).

It is possible to gray-out (or italics) these admin roles in the list (but still allowinf them to be selected) so the user can see difference easier. But regarding comment 4 that would introduce difference in UI behavior common to other parts.

For every action there are multiple tests performed in the backend before its actual execution. Reimplementing/Reusing them in the UI should be rather considered as a new feature than a bug fix.
Comment 7 Marek Libra 2015-10-30 03:53:25 EDT
Another option might be sorting them for admins, i.e.: user roles first, then admin ones
Comment 10 errata-xmlrpc 2016-08-23 16:30:10 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://rhn.redhat.com/errata/RHEA-2016-1743.html

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