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(a)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.