Hey Aaron, thanks so much for looking at this. On Dec 18, 2012, at 8:50 AM, Aaron Weitekamp <[email protected]> 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-permissions/ >> >> 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-ConductorRolesEvaluation2012-11-07.pdf > 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-17.pdf > > * 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
