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¶