View source | View content page | Page history | Printable version   

Projects:Role Inheritance/Functional&Technical Specifications



The objective of this project is to ease the management of the role creation. The implementation of this project will help to define role permissions (access to organizations, windows, reports, process etc.) by inheriting them from other already existing role permissions. This will allow to define a dynamic role inheritance hierarchy.

Functional requirements

With this new mechanism, the role management will be simplified, allowing the generation of the new roles on a hierarchy based procedure: the new role will inherit the permissions copied from other already existing roles.

The way to define role permissions based on inheritance will be done through a new tab, [Role Inheritance], included in the [Role] window. Inside this tab, it will be possible to create new records in order to specify the role whose permissions will be copied into the new role. Every record in this tab will have two fields:

Using this configuration, the accesses for the new role will be generated in the corresponding tabs where the permissions are defined, for example, in the sub-tabs of the [Role] window. Also a new field will be included in all those tabs:

Use Case 1 (Horizontal Hierarchy)

With the current role definition design, if an entity has multiple organizations, users are forced to define the same role per organization multiple times, depending on the organization structure.

The generation of new roles can be done in a flexible way with this mechanism. We can create a role with access to the organizations and one role with the application elements we want to access with the new role, and generate a new role that inherits the permissions from both roles (See image below).

Role inheritance.png

Use Case 2 (Horizontal Hierarchy)

Let's say that we have a sales role and a purchase role. We can use our new way to configure roles to grant access to sales and purchase elements to a new role automatically.

Role inheritance 2.png

Use Case 3 (Horizontal Hierarchy)

By using the sequence number, we can define the order which the permissions will be inherited. This will allow us, for example, to restrict access to the elements by using the active flag.

Role inheritance 4.png

Use Case 4 (Vertical Hierarchy)

It will be also possible to define the permissions inheritance in a vertical hierarchy. This will make possible to reflect changes done in a parent node (role A in image below) to its child nodes (role B) and subsequent child nodes (role C).

Role inheritance 3.png

Technical requirements

This project will take advantage of the current infrastructure for securing the application elements. So it does not require to review or change the current logic which gives access a particular role to those elements.

A new way to configure roles is going to be introduced, but this roles will be defined in the same way as it is done manually.

To make this configuration work two implementation parts are involved: the application dictionary infrastructure and a process to manage the inheritance. Apart from these two parts, it would be nice to have a widget or window in order to allow users to see a role inheritance tree in a friendly way.

Application Dictionary Infrastructure

It is necessary to create an application dictionary infrastructure which allows users to create the role configuration. The required application dictionary elements are:

Note: the users assigned to the roles will not be managed by this project and therefore will not be inherited by the newly created roles. So the [User Assignment] tab in the [Role] window will remain unchanged.

Process to manage permissions inheritance

A process must be defined to manage the creation of the inherited permissions. This can be achieved using an event handler fired when creating, removing or editing records in the [Role Inheritance] tab.

This process will use the role and the sequence number of the records created in the [Role Inheritance] tab, to add the permissions of the new role.

The roles selected to inherit from should be the ones marked as "Is Template". They can be selected in the selector that will be present in the records of the [Role Inheritance] tab. This is intended in order to avoid problems when making changes in role that otherwise could be extended through the entire hierarchy. In addition, the roles candidates to be selected should be of the same access level as the role that will be created.

Besides, it should not be possible to set as non-template an existing template role being used by other roles. A template role must be Manual, i.e., it can not be defined as Automatic.

This will be an additive process, i.e., all the permissions will be copied into the new role and if we need to restrict access to a particular element, then the permission for that element should be copied with the active flag as false.

For example, if we have the following hierarchy A->B->C and A has access to a window, this access will be included during the process for the role C. In case role B does not has access to that very same window, it will have the active flag set to false. Therefore the final permission given to C for that window will be revoked.

For those permissions created manually, they will remain unchanged after setting the inheritance for the role. So, this process will not modify permissions created manually. In the same way, users can not modify an inherited permission.

Also, this process will take into account the preferences defined for a role and it will create them for the new role as part of this inheritance process.

Finally, it must also check that there is not any cycle in the defined hierarchy.

Recalculate Permission Process

When setting inheritances between roles, using the [Role Inheritance] tab, all the permissions will be propagated automatically.

But there are two cases where it would be necessary to force the recalculation of the inherited permissions:

  1. We create Role A, and we manually give it access to Sales Order window.
  2. Create Template B, and we manually give it access to Sales Order window also.
  3. Configure Role A, to inherit from Template B. Role A will inherit all the permissions from Template B. But the permission for Sales Order window which Role A already has, will remain unchanged. (As it has been created manually).
  4. Delete Sales Order permission from Role A. Due to the technical limitation mentioned above, the Sales Order permission from the template will not be added automatically.

In these cases, it would be necessary to recalculate the permissions of the role in order to avoid having inconsistencies on the inheritances. For this reason, a process to recalculate the permissions is going to be included, which will be hidden by default, as these uses cases are out of the common flow when configuring roles.

Retrieved from ""

This page has been accessed 1,426 times. This page was last modified on 22 April 2016, at 07:30. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.