+++ This bug was initially created as a clone of Bug #773580 +++ Description of problem: A non-admin user should have more consistent views of the administer pages. Buttons that lead to empty pages with "You have insufficient privileges to perform the selected action" messages seem not ideal. Version-Release number of selected component (if applicable): Current 1.0-staging version. How reproducible: Login as a non-admin user and click around the ADMINISTER section Expected results: a) buttons that lead to blank "insufficient privilege" pages should be removed b) since non-admin users can still have admin privileges on individual items, it does make sense to have the overall ADMINISTER navigation visible, right. . . ? Or no?
Yes, this is correct -- although we have a catch-all "Administrator" role, the implementation does not (should not) rely on that. There are limited admin roles on some subset of the resource types on the 'administer' section, and there are even non-admin roles that need access there, since "Administer" isn't a task-centric grouping, it's a resource-centric grouping. For example, if a user has access to view (but not administer) providers, those would be seen under the 'administer' tab, since that's where providers are. I've elsewhere suggested that we should rename 'Administer' to something else that reflects reality a bit more accurately, but I'm not sure what a better term would be. In the meantime, any link to something that the currently logged-in user doesn't have permission to access should be hidden. However, we should never check for the "Administrator" role, since the required permission could be obtained via one of the more limited admin roles (or even as an explicit permission grant on an individual provider, etc. Basically any time we have a page that uses require_privilege to raise an error for under-privileged access, we should hide any links to that page based on the same privilege level (using the permissions helper methods to conditionalize the link rendering as we're already doing in some cases) In particular, the "Administer" tab itself goes to the users index (which is unavailable for non-admins) -- this link should go to a more available page -- either always (for consistency), or at a minimum for non-user-admin users, so a user with legitimate access to, say, catalogs or hardware profiles but without access to the users list can still navigate here.
I should also note that the same should be done for the 'Monitor' section -- as I'm pretty sure we show links/actions there that aren't valid for less-privileged users as well.
moving to 1.1
Wes -- no need to move this to 1.1, as I just posted a patch for it Moving back to 1.0 -- patch posted at https://fedorahosted.org/pipermail/aeolus-devel/2012-January/008420.html I've basically gone through the site as a non-admin user and for every link I could find that took me to a page that told me I wasn't allowed to access the page, I conditionalized the link to that page and hid it based on the same privilege check that tripped up the user upon following it. Also, in some cases I hit these permission error pages because we weren't filtering content properly -- pool families page showed all pool familes, not just those with permissions. Likewise the deployment and instance lists on the pool side were showing all, not just those that the user had permissions for.
Commit pushed to 1.0-staging: dbbdb7245754d49fa3c871269c36f95f2373fd75
dbbdb72 in aeolus-conductor-0.8.0-17
i still some pages with "Insufficient Privilege" message Some of them are listed below : 1) User --> Delete https://ibm-ls22-04.rhts.eng.brq.redhat.com/conductor/users/2 2) Clouds --> New cloud Resource Zone 3) Clouds --> Default pool -->Edit 4) Catalogs --> delete catalog
OK for 4) above the 'delete' actions for the list items are a bit trickier, since permissions are on a per-object basis in the list. Basically for lists, the 'delete' action is available, but if you try to delete several items, only the ones you have permission on get deleted, and the return message outlines what was deleted and what was not. Longer-term, we probably need some sort of automatic javascript-oriented solution that disables actions that you can't perform based on what's selected. Since in some cases there may be more than one action possible, the filtering/disabling will need to be on a per-action basis. I'm assuming that will be out-of-scope for now, though. I'll look into 1), 2), and 3) as it looks like those ought to be easily resolved.
OK I see 1) and I'm removing the 'delete' button for non-admin users. However I'm not seeing 2) or 3) when logged in as a non-admin user. What URLs are you on where you see these options? What site-wide roles is this user assigned? What about on the pool itself (where the edit link shows up)?
Setting needinfo to the QA contact.
Tested it again , there are a set of buttons which show message "Insufficient privileges" depending on different roles : Listing some of them below : Zone Global User ================================= Administer – Clouds-- > Component Outline Page Monitor --> Default catalog --> Edit Default btn Administer – > Clouds Administer – > Content-->hardware -->Delete selected btn Administer – Content-->Catalog -->Delete btn Administer – Content--> Default-->Delete Blueprints Administer – Content--> Default--> Blueprints -->”Comp Outline Valid” btn Zone Administrator ========================================= Administer – Clouds-- > “New Component Outline” btn Administer – Clouds-- > Component Outline page Administer – > Content-->hardware -->Delete selected btn Administer – Content-->Catalog -->Delete btn Administer – Content--> Default-->Delete Blueprints Administer – Content--> Default--> Blueprints -->”Comp Outline Valid” btn Provider Admin ==================================================== Administer –Filter View -->Zone -->destroy Administer –content –App Bluprint -->Delete button Administer-->Content -->Launch Page -- >Add catalog btn Administer-->Content -->Launch Page -- >Component Outline Valid btn Provider Creator ====================================================== Administer –Filter View -->Zone -->destroy Administer –content –App Bluprint -->Delete button Administer-->Content -->Launch Page -- >Add catalog btn Administer-->Content -->Launch Page -- >Component Outline Valid btn Catalog Global user ====================================================== Monitor -->catalog dropdown Monitor --> FilterView -->Zone –> Destroy btn Administer --> Content -->catalog -->delete btn Administer --> Content -->catalog -->App Blueprint ->delete btn
There is another bug logged for this https://bugzilla.redhat.com/show_bug.cgi?id=798278
> > Zone Global User > ================================= > Administer – Clouds-- > Component Outline Page I think this is correct. We don't have low-level image permissions in this release. Image access is based on 'cloud' permissions, and 'Zone Global User' includes view rights on all clouds. In any case, this view is not currently filtered. > Monitor --> Default catalog --> Edit Default btn I'm not seeing this. I don't see a 'Default catalog' link under Monitor. What is the exact sequence of links to click to see this? > Administer – > Clouds This takes the user to the list of clouds they have 'view' access on, which will probably include at least one for an average end user, and will include all Clouds for users in the 'Zone Global User' role. > Administer – > Content-->hardware -->Delete selected btn This is fine. Delete permissions are based on individual profile permissions. We'll need a javascript-based solution to automatically enable 'delete' based on current selection, but that's post-1.0 scope. > Administer – Content-->Catalog -->Delete btn This is fine. Delete permissions are based on individual catalog permissions. We'll need a javascript-based solution to automatically enable 'delete' based on current selection, but that's post-1.0 scope. > Administer – Content--> Default-->Delete Blueprints This is fine. Delete permissions are based on individual blueprint permissions. We'll need a javascript-based solution to automatically enable 'delete' based on current selection, but that's post-1.0 scope. > Administer – Content--> Default--> Blueprints -->”Comp Outline Valid” btn Good catch here! This should be disabled as a button -- and should be information only. > > Zone Administrator > ========================================= > Administer – Clouds-- > “New Component Outline” btn Yes, this should be hidden. > Administer – Clouds-- > Component Outline page This view isn't currently filtered. I'm not sure what the real requirements are here, as we don't have detailed per-image permissions -- we could filter each image based on permissions on the containing Cloud, although that might be slow. We could also hide this whole page unless the user has global Cloud view permissions (such as a 'Global Zone User' or 'Administrator') > Administer – > Content-->hardware -->Delete selected btn > Administer – Content-->Catalog -->Delete btn > Administer – Content--> Default-->Delete Blueprints > Administer – Content--> Default--> Blueprints -->”Comp Outline Valid” btn > These four are addressed above. > Provider Admin > ==================================================== > Administer –Filter View -->Zone -->destroy I'm not seeing the 'destroy' link here. > Administer –content –App Bluprint -->Delete button Addressed above > Administer-->Content -->Launch Page -- >Add catalog btn Good catch here too. This needs to be fixed as well. > Administer-->Content -->Launch Page -- >Component Outline Valid btn > Yes as mentioned above, this should be fixed > > Provider Creator > ====================================================== > Administer –Filter View -->Zone -->destroy > Administer –content –App Bluprint -->Delete button > Administer-->Content -->Launch Page -- >Add catalog btn > Administer-->Content -->Launch Page -- >Component Outline Valid btn > Provider Creator is gone as of the latest commits, so I won't worry about this section. > > Catalog Global user > ====================================================== > Monitor -->catalog dropdown > Monitor --> FilterView -->Zone –> Destroy btn > Administer --> Content -->catalog -->delete btn > Administer --> Content -->catalog -->App Blueprint ->delete btn > This role is lumped in with 'Zone Global User' now, and these three are addressed above.
To clarify, it looks like the only things left to fix here are as follows: > Zone Global User > Administer – Content--> Default--> Blueprints -->”Comp Outline Valid” btn Good catch here! This should be disabled as a button -- and should be information only. > Zone Administrator > ========================================= > Administer – Clouds-- > “New Component Outline” btn Yes, this should be hidden. > Administer – Clouds-- > Component Outline page This view isn't currently filtered. I'm not sure what the real requirements are here, as we don't have detailed per-image permissions -- we could filter each image based on permissions on the containing Cloud, although that might be slow. We could also hide this whole page unless the user has global Cloud view permissions (such as a 'Global Zone User' or 'Administrator') > Provider Admin > Administer-->Content -->Launch Page -- >Add catalog btn Good catch here too. This needs to be fixed as well.
On the right way to handle "Administer – Clouds-- > Component Outline page", for 1.1, an unfiltered list is sufficient.
Patch on list: [PATCH conductor] bug 784108: Hide additional links for non-privileged users. Several of the original reported problems had already been fixed. The patch on list fixes the following: "Images Valid"/"Repair Images" links are disabled if the user doesn't have edit permission on the deployable On the deployables list, the "add catalog" form filters the dropdown by catalogs that the user has permission to add to, and the form is hidden entirely if the user doesn't have edit rights on the deployable On the Environments index page, the add image links and edit pool links are hidden for users without permission to perform those actions
On master at: 38faa482770cef13aa2c9da608b852e8dd9c2354 On 1.1 at: fface3c9733901d4cf1329c7c2c5539b8e1590fb
in build aeolus-conductor-0.13.3-1.el6cf
For Gloabl HWP user:- 1.Images valid buttonn is disabled ,edit,exit xml links are hidden. 2.Add/Import image button is hidden,although by clicking "default" pool(detailed pool view) edit/delete button is available but proper error message("You have insufficient privileges to perform the selected action") is shown when tried to edit the pool. Expection with the patch mentioned in comment#16 is met.Overall UI feel of a under privileged user is much better. Marking as verified.Verified on: [root@dhcp201-113 ~]# rpm -qa|grep aeolus aeolus-conductor-doc-0.13.7-1.el6cf.noarch aeolus-all-0.13.7-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-0.13.7-1.el6cf.noarch aeolus-conductor-daemons-0.13.7-1.el6cf.noarch [root@dhcp201-113 ~]#
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. http://rhn.redhat.com/errata/RHEA-2012-1516.html