Created attachment 573648 [details] rails log Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Create new user with "global provider user" role (along with the default roles) 2.click on "cloud resource provider" Actual results: it displayed 'You have insufficient privileges to perform the selected action '(PFA:ss1.png) Expected results: As per the doc "global provider user" is allowed "View Provider" and "User Provider"(URL;https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Roles_list) Additional info: rpm -qa | grep aeolus aeolus-conductor-0.8.3-1.el6.noarch aeolus-conductor-daemons-0.8.3-1.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-configure-2.5.2-1.el6.noarch aeolus-all-0.8.3-1.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-conductor-doc-0.8.3-1.el6.noarch attached rails.log
Created attachment 573649 [details] ss1
Hmm. I noticed this a couple days ago, but it wasn't obvious initially how to resolve it. The problem is that when we designed the UI we decided that, for providers (and _only_ providers), the default view was to be the 'edit' page. As a result, you can only get to the provider details if you have permission to edit the provider. Possible solutions: 1) fix the UI such that Providers has a proper view page that links to 'edit' as appropriate (like we do everywhere else) 2) keep the UI as-is, but change permissions to allow 'view only' users access to the 'edit' page (with plenty of comments to indicate that we know it's deliberate) but hide the 'save' button from these users I prefer 1) longer-term, but 2) would be a quicker fix
updating the scenario observed for 'object level permissions' also 1. create a user with "global image admin" role 2. given "provider user" role('object level permissions') observed that when tried to access the provider it displayed "'You have insufficient privileges to perform the selected action" Added this to cover the 'object level permissions' also
We'll do fix #2 (comment 2) for z-stream, fix properly in 1.1.0
Patch posted at: https://fedorahosted.org/pipermail/aeolus-devel/2012-May/010559.html For provider accounts, the 'edit' action doubles as the 'show' page. This meant we were requiring modify privileges on the provider to even see the provider pages. This patch relaxes the checking to reqiure only view permissions, and in the views we hide the edit/modify actions from users that don't have the higher privileges, and the form elements are made read-only.
Pushed to master with: c8e2f50fcc10c4183d798fa1625d525a8c4b89d2
1. A user with "Global Provider User" role is able to view provider page but not able to see various provider account.(New/edit both are hidden).(expectation matched). 2. A user with object level(say here object is ec2-us-east) "Provider User" role is able to view only that provider.Again this user is not able to see various provider account.(New/edit both are hidden).(expectation matched). Verified On:- [root@dhcp201-113 ~]# rpm -qa|grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-all-0.13.8-1.el6cf.noarch aeolus-conductor-0.13.8-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch aeolus-conductor-daemons-0.13.8-1.el6cf.noarch aeolus-conductor-doc-0.13.8-1.el6cf.noarch
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