For anyone interested in the Conductor permissions UIs

Aaron Weitekamp aweiteka at redhat.com
Wed Dec 19 15:32:09 UTC 2012


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 at redhat.com
> <mailto:aweiteka at 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.



More information about the aeolus-devel mailing list