Hey Aaron, thanks so much for looking at this. On Dec 18, 2012, at 8:50 AM, Aaron Weitekamp <aweiteka(a)redhat.com&gt; wrote: This is the first presentation, but I think you are actually referring to the new document, which is here: http://www.aeolusproject.org/docs/presentations/misc/Conductor_Roles_2012... When we are looking at the role assignment screen, we are showing all permission grants from external resources (non-direct grants), plus allowing direct grants to be modified. For the non-direct grants, we show the context and provide a link to the resource or place where that permission can be modified. The reason we aren't allowing the removal for inherited permission here (or on any child where inheritance from a parent applies) is for simplicity's sake - that permission is on another object, so we don't manage it here. If we allowed the removal of the permission on the parent from here, other resources are affected, and that can be confusing. So we give you a link to the parent, and from there you can decide if you want to change the direct permission on that resource. The name of the parent is included beside the role name in parenthetical. For now, The hover for "Yes" is being used only for enumerating groups for grow grants, however it could be used to replace the parenthetical I show on 19. Similar to inheriting from a parent resource, because this is a non-direct grant applying here, this provides a link to a place to change the global role which grants permission on this resource. I thought this too until I met with Scott and realized by reading the role descriptions. It is possible - and desirable - to have multiple roles on a given object. The roles here are not subsets. "Resource Zone AppForm Blueprint Administrator" doe not have all of the permissions that "Resource Zone User" has. If you want someone to be able to manage the AppForm Blueprints AND be able to launch apps in a RZ, they need both of those roles. The useful action here is to add an additional role to any existing role they may have. Again, because they may need more than one role to have the appropriate permissions. I don't show a cursor on 23 to guide you, but this is just if you clicked "Edit Roles" on page 23 for the user tjones. I think the context shown is correct. You shouldn't have to leave the resource to manage one user or one group's access to it. It is the same content as p12 but starting from the resource, not the user. yes, but not in the scope for this presentation - its more a part of the two pane itself.

On 12/19/2012 10:32 AM, Aaron Weitekamp wrote: Yeah, this is a comment on the model itself rather than the UI. The thing is a role is a collection of lower-level privileges. In some case "higher" roles are supersets of the privilege list of the "lower" ones, but not always. The obvious examples of this in the current implementation are the global roles -- there is the all-inclusive Administrator role that includes everything, but there are then several other global roles that focus on specific areas, so they're not subsets/supersets of each other. Once you have the possibility of two different roles on a resource that each contain a privilege that the other does not, you have to allow for the possibility that you need to assign both in some cases. The other case where you'll see more than one role on a resource is when you have one role given to you directly and another indirectly either via object inheritance (i.e. grant on the pool which gives you certain rights on an instance), or via group membership (you belong to a group that gives you 'resource zone user' but you're individually granted 'resource zone admin') -- it's important to see the additional roles granted there, so that it is clear that if you revoke the 'resource zone admin' rights, the user will still retain the rights conferred in those inherited or group-based role assignments. Also, at an API level, roles are editable. An admin will at some point be able to change what privileges are associated with a role and even add new ones, so we can't really make assumptions about how often roles are structured in such a way that one is always a subset of the other. I think the best way to avoid confusion is to include a way to indicate in the UI what privileges each role includes, as Jeremy has done in these designs. I'm not looking at the page at the moment, but at a higher level, there are two basic ways of accessing permission grants. A permission grant is the assignment of a role _to_ a user or group _on_ a resource. So the primary way of interacting with permission grants is from the resource page -- each permissioned resource provides a sub-section or tab in the UI to show and manage permission grants on that resource. For example, the 'show' page for a 'resource zone' has a 'permission grants' tab that shows the users and groups that have access to this resource, both direct and indirect. On this page you can add/remove direct grants and view inherited grants. The user and group profile pages do the same thing from the opposite side of the relationship. They show the list of resources that the user (or group) has been granted permission to access, both direct and indirect. On this page you can also add/remove direct grants and view inherited grants. Scott