Bug 1273025

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