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

Role

This article is protected against manual editing because it is automatically generated from Openbravo meta-data. Learn more about writing and translating such documents.
Back button.png   Back to General Setup


Contents

Introduction

The aim of a role is to group user/s depending on what parts of Openbravo they are allowed to access to and therefore to work in.

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

Automatic Roles

An automatic role, unlike manual role, allows access to all elements based on the user level defined as System, Client, Organization, or Client+Organization. All elements will be visible as defined by the user level, without the need to create them manually. They have also access to all organizations.

It is possible to revoke access to any element by creating a record in the corresponding tab and marking this record as not active.

Role

Role window allows to review, create, configure and maintain the roles to use in a given client.

Role Window.png

As already described there are roles automatically created by Openbravo which can be reviewed in this window.
Besides this window allows to create new roles for a given client. Roles creation can properly be done by using a Client Admin user & role.

The fields to fill in are:

Automatic Roles

An automatic role, unlike manual role, allows access to all elements based on the user level defined as System, Client, Organization, or Client+Organization. All elements will be visible as defined by the user level, without the need to create them manually. They have also access to all organizations.

It is possible to revoke access to any element by creating a record in the corresponding tab and marking this record as not active.

Org Access

Org Access tab allows to define the organization/s to which a given role will have access rights to.

As already mentioned every record in Openbravo belongs to an organization, therefore the only way for a user role to edit a record which belongs to an organization is to provide that user role with access to that organization.

Org Access Tab.png

User Assignment

User Assignment tab allows to add users to a given role.

User Assigment Tab.png

"Role Administrator" checkbox allows to the user to admin the given role for:

Bulbgraph.png   As Role Administrator flag allows to modify behavior of other users with the same role, it should only be granted to trusted users.

Window Access

This tab lists and/or allows to add the windows to which a role will have access to.

As already mentioned every time a new role is created and saved without selecting the "Manual" checkbox, Openbravo automatically fills in all the windows in the Window Access tab.
Above means that the newly create role will have access to every Openbravo window.

Window Access Tab.png

Having said that, if the "Manual" checkbox is selected, it will be required to manually add a subset of windows which will be accesible for a given role, or it will be required to automatically add them by using the action process "Grant Access". This process will allow window access for a given Openbravo module or area such as Projects, Finance or Sales.

Editable Field checkbox defines if the accessible data in a window can be edited by the role or not.

Tab Access

Defines whether a tab is editable or read only for a concrete role.

Bulbgraph.png   This is a Premium functionality. Learn more about the benefits of Openbravo's commercial editions

In a window accessible by a role, it is possible to define for each of its tabs if they are editable or not through the Editable Tab check.

If the window is editable (Editable Field is checked), by default all its tabs will be editable. But it is possible to define some of them not to be editable for this role by adding them in this tab and setting to false the Editable Tab check. Note this is only true if the table behind the tab is editable for the role.

In the same way, having a non editable window it is possible to define some of its tabs as editable by checking Editable Tab.

Field Access

Defines whether a field is editable or read only for a concrete role.


Bulbgraph.png   This is a Premium functionality. Learn more about the benefits of Openbravo's commercial editions

Field Access tab works very similarly to Tab Access tab, allowing to define write access up to a field granularity level.

So if a tab is editable for a role, a concrete set of fields in that can be made read-only for that role adding a new row in this tab for each field and setting false Editable Field of each of them. Or in the other way around: in a non editable tab, fields can be editable if they are added and their Editable Field property is checked.

When editing a tab with some fields defined not to be editable in this way, backend checks modifications of them from that tab to prevent this to happen. Note this also affects the field in case it was modified by for example a callout or a default expression. This is controlled by the Check on Save property, unflagging it, this check will not be performed allowing thus the field to be modified by a callout.

Report and Process Access

This tab lists and/or allows to add the reports and processes to which a role will have access to.

As already mentioned every time a new role is created and saved without selecting the "Manual" checkbox, Openbravo automatically fills in all the reports and processes in the Report and Process Access tab.
Above means that the newly create role will have access to every Openbravo report and process.

Process Access Tab.png

Having said that, if the "Manual" checkbox is selected it will be required to manually add a subset of report and process which will be accesible for a given role, or it will be required to automatically add them by using the action process "Grant Access". This process will allow report or process access for a given Openbravo module or area such as Projects, Finance or Sales.

Editable Field checkbox defines if the accessible data in a report or process can be edited by the role or not.

By default, access to processes in a standard window invoked from a button, is inherited from the permission to the window. So if the role has access to the window, it will be possible to execute all the processes defined in that window regardless there are explicit entry for them in Report and Process Access tab. This default behavior can be changed in two different manners:

Form Access

This tab lists and/or allows to add the forms to which a role will have access to.

As already mentioned every time a new role is created and saved without selecting the "Manual" checkbox, Openbravo automatically fills in all the forms in the Form Access tab.
Above means that the newly create role will have access to every Openbravo form.

Form Access Tab.png

Having said that, if the "Manual" checkbox is selected, it will be required to manually add a subset of forms which will be accesible for a given role, or it will be required to automatically add them by using the action process "Grant Access". This process will allow form access for a given Openbravo module or area such as Projects, Finance or Sales.

Editable Field checkbox defines if the accessible data in a form can be edited by the role or not.

Widget Class Access

This tab lists and/or allows to add the widget classes to which a role will have access to.

Widgets are User Interface elements which can either be placed in the Users' Workspace tab or be part of a generated window.

View Implementation

View implementation tab allows to select customized views.

A view implementation is a completely custom implementation of a main view.
The access to a custom view can be controlled through this role access tab.

For additional information about views, visit How to implement a new main view.

Process Definition

Grants access to Process Definition. By default, access to process definitions in a window (invoked from a button), is inherited from the permission to the window. To revoke this inherited access and manually decide case by case which are the accessible processes, it is necessary to define a "Secured Process" Preference (at system level or for that specific window) with "Y" as value.

Access when the process is invoked from a standard window button is inherited in the same way that for Processes.

Role Inheritance

Allows to define an inheritance for a role. An inheritance is a relationship between two roles: if role A inherits from role B, that means that all the permissions that role B has for different application elements like organizations, windows, reports, processes, widgets etc. will be automatically inherited by role A, allowing it to access those elements in the same way as B. It is also possible to define an inheritance hierarchy, i.e., a role can inherit from different roles, and the priority (order) to inherit the permissions is defined by the sequence number. This means that if two inheritances have accesses in common, the accesses of the inheritance with lower sequence number will be overridden with the accesses of the inheritance with higher sequence number.

Within this tab is where the Role Inheritance configuration of a particular role is set.

Role inheritance tab.png

The fields to fill in are:



Full list of Role window fields and their descriptions is available in the Role Screen Reference.

Back button.png   Back to General Setup

Retrieved from "http://wiki.openbravo.com/wiki/Role"

This page has been accessed 36,981 times. This page was last modified on 21 October 2015, at 18:51. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.