This ticket is related to #47. It is next step in evolving the flexibility of the UI views based on administrative function of the user. In #47 we just do all UI or just self service. This ticket calls for creation of the centrally manageable facility for defining flexible UI views.

The solution should consist of:
- Schema (extensions to the role groups) that would define which screens user can see in the UI
- Management plugin for UI/CLI to manage this data
- Preloaded data for all preconfigured administrative roles
- UI screen(s) to alter set of UI screens associated with the role

Some thoughts about the design:
- Schema should extend the role group probably by adding some special MV attribute via a AUXILIARY class.
- There should be a list of all possible screens somewhere in the configuration files. It is not required to have them in LDAP should it would be helpful too. The list will contain the screens ID names in the hierarchical way. For example:
- Identity
- Identity.users
- Identity.users.details
- Identity.users.group
- ...
The definition of the allowed screens will boil up to filling in the MV attribute with the subset of the entries from the whole list (or removing the ones that are non needed). Selecting a Z level entry X.Y.Z will cause the entries X and X.Y be added to the list automatically. Removing X level entry will remove X.* and so on. When a new role group is created I think it should be pre-filled with all options.
- The whoami plugin will collect all role groups and return the merged list of the screens allowed for the user
- The list will be stored in the session cookie
- Changes to the roles and UI views will invalidate the cookie and restart the session
- The UI will no display screens not mentioned in the list for the user