Enhancements to Admin Console Roles editor

[amcclain]

As our initial release of the new Hoist-provided role manager settles in, a few enhancements and issues have come up:

Tree viz resets on app auto-refresh

It's often helpful (or essential) to collapse nodes in the tree viz to allow other node labels to be printed, or to generally focus down on one part of the tree. Unfortunately if the admin app's background auto-refresh is active, the tree resets on you.

Ability to view a Roles own memberships in a grid from the detail panel.

The Role detail panel lists all members of the role in the tabbed-grids for direct and effective members. However if you wish to check if the given role belongs to any other roles itself, the only way to do so is via the tree viz. It would be helpful to have a grid-based listing of the role's own memberships.

This could start with (and maybe end with) a listing of all direct memberships only. We could explore also providing an option to view effective memberships, but only if it seemed like a clear net benefit. If we had that symmetry between the views on members and memberships, perhaps it help to clarify even more. (See next item.)

Ability to edit a Role's memberships in addition to its members

When working with "higher-order" roles that exist to roll-up other roles, it's a common use case to create a new role and then immediately add it as a member to a number of other roles. I.e. I might create a new "Middle Office Managers" role and then want to grant it a number of other existing roles like "APPROVE_PNL" and "UPDATE_PRICES". In some cases there might be a decent number of these roles you wish your new role to join. Currently a user must create the new role, then close it, then visit all the other roles and add the new role to each one individually.

Being able to edit a Role's memberships in other roles in addition to its user/group/role members could also help to clarify the direction of the existing editable member roles grid. I'm finding it easy for admins (self included) to confuse the direction of the current member roles grid. When e.g. editing an "Operations Managers" role it's just so natural to think "I am editing the ops managers role, and here's a nested list of roles within this editor. I will add roles to this list and then the ops manager role I am editing will have those roles." But that's backwards!

Ability to rename a Role

Complicated somewhat by use of role name as primary key - we've discussed this could be implemented as a delete + recreate option. Did not initially seem like a priority feature, as we were thinking about relatively static roles that are referenced in code, but when we started to use the editor to build out a hierarchy of "business roles" that are not referenced in code, we found that we often wanted to refine and adjust some initial naming choices, but it can be a real pain to do so.

Ability to spec (lightweight) Category heirarchies

We've used an approach in another (completely different) context where we support a power user option to specify a single category name/string using the ">" to denote a hierarchy. It would be great if we could spec categories like "Business Roles > Operations" and "Business Roles > Middle Office" that then caused the category group-by in the grid to nest roles under a top-level "Business Roles" group with child "Operations" and "Middle Office" groups.

This could be very helpful for organizing larger sets of roles, without needing to define some more elaborate multi-level hierarchy or data model for categories up front.