Most Powerful Open Source ERP

ERP5 How To Set User Access Permissions

How to showing walking through setup of viewing permission.
  • Last Update:2017-01-21
  • Version:002
  • Language:en

This document shows and explains how security permissions are set in ERP5 using the 5A Security Model. The content is also available on this legacy document. A more theoretical and in-depth introduction can be found in understanding the 5A security model

.

Table of Contents

ERP5 Security Model Overview

The following example will walk you through setting up security permissions in ERP5 while explaining the underlying concepts.

Permission Complexity

Usually in a Zope application we create users and roles and thereafter associate roles to users. For example, Mr. Y is assigned the role of Principal Cashier and Mr. X is assigned the role of Accounting Manager. In a real world ERP applications the number of users and roles can become very large which may make security completely unmanageable.

To counter this problem, ERP5 uses the concept of Group Indirection to reduce the number of roles through the use of groups. Hence instead of assigning Mr. X, the role of Accounting Manager, we make him a member of the group of Accounting Managers and then associate this group to the role of Assignor, which is one of the 5 generic local roles in ERP5.

For security configuration in ERP5, we use a minimal number of 5 generic local roles. They are Author, the document creator; Assignor, the one who assigns a document to an Assignee, also a local role; Auditor, one who has complete access to document contents and Associate, a participant in document processing. These are explained in more details in another document. This helps in managing security efficiently even if the number of users and groups grow to very large numbers.

Hence in ERP5, we can create several groups and thereafter associate each group to an appropriate generic local role. This is demonstrated by an example in the following pages.

Static Local Roles

To denote the fact that a given user is working as a Accounting Manager for a particular group located at a certain site and has certain rights we use the Roles tab in portal_types. For every possible role, seven fields are provided to define the security policy: Title, Roles, Description, Condition, Base Category Script, Base Categories and Categories.

The Title field denotes the common name, as is used by an implementer to refer to this role such as "Accounting Manager". Roles is used to specify one of the 5 generic local roles in ERP5 such as Assignor. Description is a text zone where you can describe this role definition. Condition denotes the basis in which this role definition would be applicable or not applicable - usually it is a TALES expression. In Base Category Script, we may reference a script that provides the machinery of associating groups dynamically, usually based on document properties. Base Categories will be the dynamic categories, returned by the base category script. Categories are the categories that ensure that the Assignor should have the function of accounting manager for the back office in "nexedi group", and in the site "france". This is denoted here by the static categories "function/accounting/manager", "group/back_office/nexedi" and "site/france".

Dynamic Local Roles

The example above is more realistic for the case of a multi-company accounting, where each accounting agent will only have access to the accounting transactions that relate to the branch of the group where this agent is affected. Here we introduce so-called dynamic categories, meaning the group is not statically defined and applied for all purchase invoices, but will be taken from the group of the vendor organisation for each invoice.

To implement such security, in the Base Categories field, we specify group. This is the category that will be dynamic, and in the Base Category Script, we reference a script that gets the category from the document, here it will take the group of the vendor of the invoice. For different cases a different script has to be used.

The function is still defined statically in Categories meaning this role definition will only be applied for persons with assignments as Accounting Agents. Another interesting point from this example is that site is not specified, which means that the site is not taken into account here.

Explaining further with another example, consider a clerk in a multi-branch, multi-country and multi-service company entering accounting transactions. The manager responsible for validating this accounting must belong to the same service and the same branch as the clerk, and this is denoted by the group and site entries respectively in the Base Categories field and he should have the function of accounting manager as denoted by the entry in the Categories field.

Account Manager Example

The main advantage of the above approach is that the definition of all local roles and mapping between common names and generic names are defined in a central place.

Let us study a more complex case where the security group is not only governed by career and human resource management but by a combination of Human Resource Management and Service Level Agreements. Extending our example of Mr. X, we state that he is in-charge of every research contract between Eurocopter and IBM. We denote this in a trade condition, which means that each time there is a contract, which is an order in ERP5 and every time a contract is being implemented it is according to an order trade condition which refers to Mr. X through the source_decision base category.

As depicted above, this trade condition has the elementary codification TCIBM and Mr. X is a member of the group RDD_COPT_TCIBM, which denotes a group of all research directors of Eurocopter, in-charge of IBM contracts. In this manner one can implement security with the concept of key account managers which may mandate that a company's documents or orders pertaining to a particular customer can only be accessed by the personnel in- charge for that customer.

Account Manager Example Security Implications

As we can see from the fields above there is not much of a change compared to the previous configuration except for the User and the Base Category.

The Title field denotes the customer's reference for this role and the Roles field has one of the 5 ERP5 local role definitions, Assignor. The Condition in this example is set to "here/getSpecialise", which means that this role definition will only be applied if there is a trade condition related to the order.

In the Base Category Script field we specify the name of the script which is used to return dynamic categories that will be used to calculate security groups. The Base Categories field has the dynamic category entry specialise which is used to denote the relation between the order and the trade condition. ERP5Type_getSecurityCategoryFromContent is a simple script that returns a category from the current object (ie. the order). Again the Categories field ensures that the Assignor should have the function of R&D director for Eurocopter group, which is denoted here by the static categories "function/research/rd_director" and "group/eads/eurocopter".

So far we have configured which groups have Assignor role on Sale Orders. The last part needed is to configure which groups a user will be a member of. This is configured in the ERP5Type_getSecurityMapping script. Here you'll have to define that "group" and "function" are taken from users open assignments, and that specialiseis taken by all trade conditions where the user is listed in the source_decision list of persons.

Related Articles