| Summary: | Pool owner perm should also grant pool user.. no need to list it twice | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | wes hayutin <whayutin> | ||||
| Component: | aeolus-conductor | Assignee: | Scott Seago <sseago> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Aziza Karol <akarol> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 1.0.0 | CC: | akarol, athomas, deltacloud-maint, slinaber, ssachdev, sseago | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | https://dhcp231-79.rdu.redhat.com/conductor/pools/2 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-05-15 21:28:39 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
So there are 2 things going on here: 1) roles are independently-defined. A role is a collection of lower-level privileges combined together. In some case, like here, one role is a subset of another, but in other cases they are not (i.e. "Provider Admin" and "Pool Admin" on the global roles). More specifically, Pool Owner doesn't grant Pool User -- rather Pool Owner and Pool User both grant the privilege of viewing pools and launching instances in them. 2) the tab was originally called "Permissions" this was changed to "Users" by the UX team. While it is incorrect that there are "2 users", there are, in fact, "2 permissions grants". Specifically, any time a user is validly added to more than one role the number won't match the number of users, as it's counting permission grants. This will be even more confusing once we start allowing permission grants to user groups here. So, as for the correct resolution: 1) we had talked about preventing a user from being assigned more than one role _if_ one was a subset of the other. The downside is we'd have to pull the privilege list for each role and cross-reference all of them across all roles to determine what to hide. I'm not sure that's a great idea here. 2) Perhaps we should re-think calling this "Users" and go back to "Permission grants" or "Role assignments" (but _not_ just "Roles") FWIW, I think that preventing users from being assigned multiple roles, where one if effectively a subset of the other, given our intention to support an arbitrary number of user-defined roles in future, would be complex adn unintuitive for the user. Changing the name to "Role Assignments" would be beneficial, as it more accurately describes the objects which the user is presented with. Patch posted: https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007400.html Permissions tab label updated from 'Users' to 'Role Assignments' No changes to multiple role assignment behavior, in agreement with Angus above. Commit pushed to master. 245fa3e6a6a97402c4aa3744a872d08e51cfa608 in aeolus-conductor-0.8.0-2.el6.src.rpm bugs in verified or on_qa moving off tracker Permissions tab label is updated from 'Users' to 'Role Assignments'. In agreement with Angus from comment 2,no changes to multiple role assignment behaviour. verified on: rpm -qa | grep aeolus rubygem-aeolus-image-0.3.0-3.el6.noarch rubygem-aeolus-cli-0.3.0-4.el6.noarch aeolus-conductor-doc-0.8.0-8.el6.noarch aeolus-configure-2.5.0-5.el6.noarch aeolus-conductor-daemons-0.8.0-8.el6.noarch aeolus-all-0.8.0-8.el6.noarch aeolus-conductor-0.8.0-8.el6.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-0583.html |
Created attachment 544625 [details] ss Description of problem: I would think that pool owner also grants pool user... the app lists the user twice and the user count increments for each.. which is also probably not good... see screenshot