| Summary: | Can't grant pool access through the "administer" tab. | ||
|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | scollier |
| Component: | aeolus-conductor | Assignee: | Angus Thomas <athomas> |
| Status: | CLOSED EOL | QA Contact: | Rehana <aeolus-qa-list> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 1.0.0 | CC: | akarol, dajohnso, deltacloud-maint, hbrock, morazi, sreichar, ssachdev, sseago |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-27 19:43:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
scollier
2011-11-04 18:59:09 UTC
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. |