Hide Forgot
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).
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.
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
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).
(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).
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.
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.
Another option might be sorting them for admins, i.e.: user roles first, then admin ones
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