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 <[email protected]
<mailto:[email protected]>> 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
