ManualDoc:T119

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:

• the Name and a brief Description of the role
• the "User level" which is a step forward "Data Access Level" to be defined at Role level.
  • User level allows to limit the records which will be accessible in entities such as windows, processes or forms for a role; or even to limit the access to a given entity for a role:
    • Every table in Openbravo has a "Data Access Level" defined. The options available are:
      • System, this level allows to see System Client records and (*) organization records, for instance application dictionary records.
      • System/Client, this level allows to see any Client record and (*) organization records, for instance master data related records such as Countries.
      • Client/Organization, this level allows to see any Client record but System Client and any Organization including (*) Organization, for instance master data related records such as Products.
      • Organization, this level allows to see any Client record but System Client and any Organization record but (*) Organization records, for instance transactional data records such as Purchase Orders.
  • User Level available options are:
    • System, if a table is defined as "System" data access level, a user role which has this user level assigned will be able to see the records of any Client including System Client records, in an entity such as a given window or form.
    • Client, if a table is defined as "System/Client" data access level, a user role which has this user level assigned will be able to see the records belonging to any Client but System Client, in an entity such as a given window or form.
      • on the other hand, if a table is defined as "System" data access level, a user role which has this user level assigned will not be able to see any record as all of them will belong to System Client.
    • Client + Organization, if a table is defined as "Client/Organization" data access level, a user role which has this user level assigned will be able to see the records belonging to any Client but System Client and any Organization including (*) organization, in an entity such as a given window or form.
    • Organization, if a table is defined as "Client/Organization" data access level, a user role which has this user level assigned will only be able to see the records belonging to a given organization but (*) organization, in an entity such as a given window or form.
  • Additionally, depending on the role's user level, no data at all is visible based on table's access level. This restriction can be bypassed starting from 3.0PR16Q3 by setting Bypass Access Level Entity Check preference to Y, the cases when entity in not accessible are:
    • If access level is System and user level is not System
    • If access level is Organization and user level is not Organization or Client+Organization
    • If access level is Client/Organization and user level is not Client, Organization not Client/Organization
    • If access level is System/Client and user level is not System or Client/Organization

• Manual check. The role automatically gets all standard user plus admin privileges, even when new elements such as windows, processes, forms, widget classes, organizations are added unless the Manual check is enabled.
  • If the manual check is enabled, it will possible to manually assign access to windows, processes, etc by manually selecting them in the corresponding tab or by using the process button "Grant Access".
  • Grant Access process button allows to select:
    • the module or application area for which access is required, modules such as Financial Management or Production Management among others.
    • and the entities of the module selected for which access is required, entities such as windows, processes or forms among others.
  • If the Grant Access process is executed for a role marked as template, the granted accesses will be propagated automatically to the roles inheriting from it.
• Template check is shown for roles which have a manual access assignment (Manual flag is Yes). Roles marked as template are those that can be used by other roles to retrieve their permissions automatically, using the Role Inheritance mechanism.
  • For this reason, just template roles can be selected in the Inherit From field of the Role Inheritance tab.
• Restrict backend access: If checked, this role will not have access to the backend (ERP). It will however have access to other applications (such as the WebPOS).
• For Portal Users: If checked, this role will have a simplified (portal) interface, where he only has available the workspace widgets. Portal interface changes the look and feel of the workspace. Top page menu and left-side menu are hidden. Usually a role for Portal Users givess access to users only to their own information using widgets.
• Portal Admin: If checked, the Portal Role will have Portal Administrator privileges.
• Is Web Service Enabled: If checked, web services will be able to obtain data for users with this role. It applies to both JSON REST and XML REST web services.
• Advanced check is shown for roles that have an automatic access assignment (Manual flag is No) and automatically grants access for such roles to all Advanced Features.
  • Manually created roles (Manual flag is Yes) have its own configuration which can include advanced features or not so this flag is not shown for them.
• Client Administrator checkbox allows a role to admin other users' Workspace as well as Customized Forms":
  • In other words, a client administrator role can assign widgets to the workspace of any client user as well as customized forms.