Bug 803715 - Changing Global Role Grants results in a "success" and "warning" message simultaneously
Changing Global Role Grants results in a "success" and "warning" message simu...
Status: NEW
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Linux
low Severity medium
: rc
: ---
Assigned To: Angus Thomas
Rehana
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-15 09:54 EDT by Ronelle Landy
Modified: 2014-01-05 13:35 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
User Roles Warning (171.86 KB, image/png)
2012-03-15 09:57 EDT, Ronelle Landy
no flags Details

  None (edit)
Description Ronelle Landy 2012-03-15 09:54:54 EDT
Description of problem:

Global Role Grants page presents the user with a number of drop-down boxes. This allows users to change multiple roles concurrently - some of which may not be compatible. Fro example:


Steps to Reproduce:
1. Logged in as admin
2. Clicked on Users -> Global Role Grants
3. Saw 5 drop-down boxes available
4. Changed the roles in three of the boxes (one box was changed from from Global Administrator to Global Application Blueprint Administrator)
5. Did *not* click on the "Grant Access" yet
6. Conductor returned the following two messages together:

Notices

Successfully modified the following User Roles: admin (from Global Administrator to Global Application Blueprint Administrator)

Errors
You have insufficient privileges to perform the selected action.

Since I changed two other roles I am not sure which one was the offending change. And, I had not even confirmed my choice before the Administrator panel went blank and conductor returned those two messages (see attached screenshot)

This may involve some user error/ user ignorance again but it was easy for me to get myself into a mess here and not have an easy way to underdo the roles I'd lost in changing the other drop-down box choices.


rpms tested:

[root@ibm-x3200m3-01 ~]# rpm -qa |grep aeolus
rubygem-aeolus-cli-0.3.0-14.el6.noarch
aeolus-conductor-0.8.0-43.el6.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch
aeolus-conductor-daemons-0.8.0-43.el6.noarch
aeolus-all-0.8.0-43.el6.noarch
aeolus-conductor-doc-0.8.0-43.el6.noarch
aeolus-configure-2.5.0-18.el6.noarch
Comment 1 Ronelle Landy 2012-03-15 09:57:40 EDT
Created attachment 570297 [details]
User Roles Warning
Comment 2 Scott Seago 2012-03-15 19:23:41 EDT
You changed your (admin's) current role to something lesser. After the change, you no longer have permission to view the roles page. So both messages are accurate -- you succeeded in re-setting permissions, but now you can't see the results of your actions. So the two error messages are correct (but confusing). Also note that, in addition to the error message, the page itself is blank.

We should probably (post-1.0 perhaps?) add some sort of warning when a user attempts to change a role to him/herself (at the same time we implement client-side js-based table/grid action enabling). This would make it more obvious what's going on.

Not in the scope of this bug, but I'd advocate changing the "no permissions error" page to actually print the permission denied in the content area of the page itself rather than as a standard error message at the top of a (now blank) page.
Comment 6 Mike Orazi 2013-01-22 16:52:02 EST
Do we intend to take action on this?  If not, let's CLOSED_WONT_FIX

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