View source | Discuss this page | Page history | Printable version   


Openbravo comes with a "super" user named "Openbravo" (password "openbravo") which can be used to sign in first time.
The Openbravo user has several roles assigned:

Finally, every time a new "Organization" is created by running the Initial Organization Setup process a new user and a new role are created and linked to each other, this time the new user role
will only enable the user to access to that Organization once signed in.

Having said that, Openbravo allows the creation of as many new "Roles" as required to be later on assigned to the existing and/or new users.

Roles group user/s depending on the tasks they do and therefore the parts of Openbravo they should have access to, parts such as windows, processes, forms, widgets and views.

Permissions Inheritance

It is possible to configure roles to retrieve their access to the different Openbravo elements automatically, by inheriting them from other "parent" roles. This configuration is possible thanks to a feature known as Role Inheritance.

Bulbgraph.png   The Role Inheritance feature is available since version 3.0PR16Q1

Having a role, it is possible to assign one or more template roles to it. This way, all the elements which are accessible by these template roles will be available automatically for that role also.

Besides, any change done in a permission of a template role will be propagated automatically to every role inheriting from it.

Notice that it is only possible to inherit permissions from template roles, which are manual roles also.

When inheriting from multiple roles, the permission application order is determined by the sequence number of each inheritance. This means that if a particular permission is inherited from multiple inheritances, the permission will be taken from the inheritance with higher sequence number.

This process eases the role management, specially when the number of roles defined for a Client is high. Thus, it is possible to define template roles to give access for a particular set of elements, and then create multiple combinations of functional roles in order to give personalized access for the different users. This is illustrated on the picture below.

Role inheritance diagram.png

The current list of inheritable elements include the following: organizations, windows, tabs, fields, processes, forms, widgets, views, process definitions, preferences and alert recipients.

For the case of preferences and alert recipients there are some restrictions to make them inheritable:

It is important to note that this mechanism takes into account the permissions manually given to the roles. This kind of not inherited accesses are not affected (not modified) in any case by the inheritance process.

It is also possible to force the recalculation of the permissions of a role, using the Recalculate Permissions process. But following the common flows of a Role configuration, all the inheritances are calculated automatically so this process is not necessary. For this reason it remains hidden.

As mentioned before, the changes (create, edit or remove) done in a permission which belongs to a template role will be propagated automatically to all the roles currently inheriting from it. For this reason, a warning message is displayed on the User Interface in order to inform users about the implications of this kind of actions.

This warning message is similar to the one shown below. It appears when creating or editing a record that belongs to a template role, in a tab of an inheritable entity.

Editing template role access.png

Retrieved from ""

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