Hide Forgot
Description of problem: To make a user an owner of a pool, need to go through monitor tab, which switches to the administer section, and there was no way to get to that via administer. Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Server release 6.1 (Santiago) Linux cf-cloudforms2.cloud.lab.eng.bos.redhat.com 2.6.32-131.17.1.el6.x86_64 #1 SMP Thu Sep 29 10:24:25 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux postgresql-8.4.9-1.el6_1.1.x86_64 mongodb-1.8.0-6.el6.x86_64 euca2ools-1.3.1-4.el6_0.noarch package gsoap is not installed ruby-1.8.7.299-7.el6_1.1.x86_64 rubygems-1.8.10-1.el6.noarch deltacloud-core-0.4.1-4.el6.noarch rubygem-deltacloud-client-0.4.0-3.el6.noarch package libdeltacloud is not installed hail-0.8-0.2.gf9c5b967.el6_0.x86_64 puppet-2.6.6-1.el6_0.noarch aeolus-configure-2.2.0-1.el6.noarch package condor is not installed iwhd-0.991-1.el6.x86_64 imagefactory-0.8.0-1.el6.noarch aeolus-conductor-daemons-0.5.0-1.el6.noarch aeolus-conductor-0.5.0-1.el6.noarch How reproducible: Every time. Steps to Reproduce: 1. click on monitor tab 2. click on pool 3. click on users 4. click on grant access, it says "Choose roles for users you would like to grant access to thisPool" 5. Can't get to that place via the "administer" tab. Actual results: Expected results: I would expect to be able to manipulate the granting of pool access directly via the administer tab somehow. Additional info:
same thing goes for granting access to a deployment. can reach this message from the monitor tab "Choose roles for users you would like to grant access to thisDeployment", but not from administer tab.
recreated [root@qeblade30 ~]# rpm -qa | grep aeolus aeolus-conductor-daemons-0.7.0-4.el6.noarch aeolus-conductor-doc-0.7.0-4.el6.noarch rubygem-aeolus-cli-0.2.0-3.el6.noarch rubygem-aeolus-image-0.2.0-1.el6.noarch aeolus-all-0.7.0-4.el6.noarch aeolus-configure-2.4.0-3.el6.noarch aeolus-conductor-0.7.0-4.el6.noarch
adding ce-sprint-next bugs to ce-sprint
I'm not absolutely certain this is the right approach. It may be that 'monitor' and 'administer' are badly named, as the distinction is not "use" vs. "administration" -- rather we've divided up the various resources based on general types of usage. However, the intent is for all actions related to pools to be done via the various tabs of the 'pool' details page. If you have the appropriate admin rights on the pool, then you see the permissions tab to add/remove users. If you don't have those rights, you simply don't see that tab. The basic idea is you find the resource in question, and then you get a page tailored to what you have permission to see. There may well be users that have permission to manage pools (including user permissions on them) but who don't have access to the resources that are currently categorized under 'administer' (including providers, provider accounts, hardware profiles, etc.) Note that the same thing happens in reverse, to "monitor" a provider, you still access provider stats under the 'administer' tab. Perhaps it's time to revisit the nav categorization to make this clearer, since the 'monitor' and 'administer' tabs really divide resources rather than functions on a given resource. Another vaguely related point (which also may ultimately help to resolve this): Since a permission grant is a role assignment to a (user, resource) tuple (i.e. "pool admin" to "John Smith" on "cloud development" pool), there are two main ways to approach the permission management UI: 1) find resource; add/remove users here 2) find user; add/remove permissions on resources here 1) is implemented today -- for any given resource type, you find the details page for that resource and then manage its permissions -- pools, instances, and deployments under 'monitor', providers, accounts, hardware profiles, etc. under 'administer' 2) is out of scope for now, but it is planned for the future. The idea is on the user profile page for a given user, an admin will be able to see all of this user's permission grants, both global (site-wide admin, etc) and roles on specific resources (permissions on pools, providers, deployments, etc). From here the admin will be able to add/remove grants for this user. 2) will be part of the 'user profile' UI, which is also currently under 'administer'
Scott makes some excellent points about improvements to the representation in the UI. Those changes are not in scope for CF 1.0, however.
moving to 1.1
moving version to 1.0.0 . version = found in version
Not sure this is actually a bug as-is. Pool access for a given pool is granted on the pool details view, which happens to be organized in the UI under the 'monitor' tab. The real bug here is that the 'administer' tab is badly named, as it gives the impression that all administration happens there. However, this tab is a resource/object type organization, not a functional one. Currently all actions on pools/zones, deployments/applications, and instances happen under 'monitor', even "administrative" ones. Longer term we probably need a more substantial reorganization of the navigation -- the current arrangement is somewhat counterintuitive and hard to find things, but that is presumably not at all in scope for 1.0
This will be fixed during the unification process with Katello -- not really a bug as much as a future feature. Marking as such.
Moving to v2.0 for consideration.