ManualDoc:W111

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:

• the System Administrator Role (this one is assigned to it by default)
  • this role enables Openbravo user to have admin rights to all the existing Clients.
• the F&B Internation Group Admin Role demo data (this one is also assigned to it by default)
  • this role enables Openbravo user to have "F&B demo data" Client admin rights.
• and besides:
  • every time a new "Client" is created by running the Initial Client Setup process, Openbravo automatically creates for that Client a "Client Admin" user linked to a "Client Admin role":
    • the client admin role enables "Client Admin" user to have admin access rights to that Client and all the organization/s of that client once signed in.
    • the newly created client admin role is also assigned to the Openbravo user by default, therefore it will be possible for the Openbravo user to access to the newly created Client.

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.

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.

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:

• A preference is inheritable if it has a template role set in the Visible At Role field.
• It is not possible to create more than one preference with exactly the same visibility settings for a template role.
• An alert recipient is inheritable if it has the User field empty.
• It is not possible to create more than one inheritable alert recipient with the same alert rule for a template role.

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.