Hi folks,
Some of you will recall the ideas I presented at the recent Brno development conference. Today I posted a significant update of this work on the blog. I appreciate any questions or feedback you may have.
http://blog.aeolusproject.org/improving-the-user-experience-for-roles-and-pe...
Jeremy
On 12/17/2012 04:49 PM, Jeremy Perry wrote:
Hi folks,
Some of you will recall the ideas I presented at the recent Brno development conference. Today I posted a significant update of this work on the blog. I appreciate any questions or feedback you may have.
http://blog.aeolusproject.org/improving-the-user-experience-for-roles-and-pe...
Jeremy
This is great, Jeremy! It's a complex problem but I've tried to understand the implementation as best I can. Here are my questions and comments on this PDF: http://www.aeolusproject.org/docs/presentations/2012-nov-conference/jeperry-...
* p.19: - I may not understand an inheritance issue, but why can't an admin remove direct grant permissions from this page? If not possible, providing a pop-up link on "yes" (see p.10) may go far in providing the user with some context. - The link to "Manage Global Roles for tjones seems out of place in this context. - I can't see a use case for ever needing to assign multiple levels of permissions so selecting multiple levels confuses me as a user. Would a dropdown be more appropriate? (my comments about p.24 may also apply--not sure yet)
* p.23: On this page we're viewing users and groups that already have permissions granted. So if I understand correctly, the "Assign role" dropdown is really "Update role" or "Edit role". In that case the "edit roles" button on each element seems redundant and confusing. If it links to p.24 see comment below.
* p.24 I'm not clear what this is but I'm pretty confused (red flag?). If we're drilling down from the previous page I think it may be clearer to display the view from p.12. I suspect I'm disoriented because we're viewing user permissions but the left pane context and heading lists a cloud resource.
* Are there any left pane batch actions? If not, are the checkboxes needed?
Hey Aaron, thanks so much for looking at this.
On Dec 18, 2012, at 8:50 AM, Aaron Weitekamp aweiteka@redhat.com wrote:
On 12/17/2012 04:49 PM, Jeremy Perry wrote:
Hi folks,
Some of you will recall the ideas I presented at the recent Brno development conference. Today I posted a significant update of this work on the blog. I appreciate any questions or feedback you may have.
http://blog.aeolusproject.org/improving-the-user-experience-for-roles-and-pe...
Jeremy
This is great, Jeremy! It's a complex problem but I've tried to understand the implementation as best I can. Here are my questions and comments on this PDF: http://www.aeolusproject.org/docs/presentations/2012-nov-conference/jeperry-...
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-12...
- p.19:
- I may not understand an inheritance issue, but why can't an admin remove direct grant permissions from this page? If not possible, providing a pop-up link on "yes" (see p.10) may go far in providing the user with some context.
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.
- The link to "Manage Global Roles for tjones seems out of place in this context.
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 can't see a use case for ever needing to assign multiple levels of permissions so selecting multiple levels confuses me as a user. Would a dropdown be more appropriate? (my comments about p.24 may also apply--not sure yet)
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.
- p.23: On this page we're viewing users and groups that already have permissions granted. So if I understand correctly, the "Assign role" dropdown is really "Update role" or "Edit role". In that case the "edit roles" button on each element seems redundant and confusing. If it links to p.24 see comment below.
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.
- p.24 I'm not clear what this is but I'm pretty confused (red flag?). If we're drilling down from the previous page I think it may be clearer to display the view from p.12. I suspect I'm disoriented because we're viewing user permissions but the left pane context and heading lists a cloud resource.
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.
- Are there any left pane batch actions? If not, are the checkboxes needed?
yes, but not in the scope for this presentation - its more a part of the two pane itself.
-- Aaron Weitekamp | Red Hat CloudForms Integration QE | IRC: aweiteka
On 12/18/2012 10:17 AM, Jeremy Perry wrote:
Hey Aaron, thanks so much for looking at this.
On Dec 18, 2012, at 8:50 AM, Aaron Weitekamp <aweiteka@redhat.com mailto:aweiteka@redhat.com> wrote:
- p.19:
- I can't see a use case for ever needing to assign multiple levels of
permissions so selecting multiple levels confuses me as a user. Would a dropdown be more appropriate? (my comments about p.24 may also apply--not sure yet)
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.
This feels a bit "over-engineered" to me. Or rather, the defined roles for a given object maybe aren't grouped properly for this implementation. For example, if I'm a "resource zone admin" it's confusing to have an option to also add me as a "resource zone user." As a sysadmin I'm then wondering if a resource zone admin can actually "use" the zone or just administer it.
Scott, do you think the roles could be defined in more "either/or" terms?
- p.24 I'm not clear what this is but I'm pretty confused (red flag?).
If we're drilling down from the previous page I think it may be clearer to display the view from p.12. I suspect I'm disoriented because we're viewing user permissions but the left pane context and heading lists a cloud resource.
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.
From a user workflow perspective it makes more sense, although I suggest we don't encourage the user to go here unless necessary; meaning, it seems like an infrequent use case if permissions are managed at the group level. It might help to have a heading (or the breadcrumb concept you mentioned is interesting) that highlights the user/object context.
On 12/19/2012 10:32 AM, Aaron Weitekamp wrote:
On 12/18/2012 10:17 AM, Jeremy Perry wrote:
Hey Aaron, thanks so much for looking at this.
On Dec 18, 2012, at 8:50 AM, Aaron Weitekamp <aweiteka@redhat.com mailto:aweiteka@redhat.com> wrote:
- p.19:
- I can't see a use case for ever needing to assign multiple levels of
permissions so selecting multiple levels confuses me as a user. Would a dropdown be more appropriate? (my comments about p.24 may also apply--not sure yet)
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.
This feels a bit "over-engineered" to me. Or rather, the defined roles for a given object maybe aren't grouped properly for this implementation. For example, if I'm a "resource zone admin" it's confusing to have an option to also add me as a "resource zone user." As a sysadmin I'm then wondering if a resource zone admin can actually "use" the zone or just administer it.
Scott, do you think the roles could be defined in more "either/or" terms?
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.
- p.24 I'm not clear what this is but I'm pretty confused (red flag?).
If we're drilling down from the previous page I think it may be clearer to display the view from p.12. I suspect I'm disoriented because we're viewing user permissions but the left pane context and heading lists a cloud resource.
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.
From a user workflow perspective it makes more sense, although I suggest we don't encourage the user to go here unless necessary; meaning, it seems like an infrequent use case if permissions are managed at the group level. It might help to have a heading (or the breadcrumb concept you mentioned is interesting) that highlights the user/object context.
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
aeolus-devel@lists.fedorahosted.org