This note explains the purpose of roles_and_users. It is to keepthe information of "who can view which documents" in the catalog.
Table of Contents
Local Role¶s¶
The purpose of the roles_and_users is to keep in the catalog the information
of "who can view which documents". It was extended for ERP5 in such way that it can also provide the
information "who has which local role on which document".
The feature "who has which local role on which document" is an extension of
the original purpose of this table with the goal to implement worklists based
on local roles. The idea is to be able to pass a parameter *local_roles* to the
request in order to filter only those documents for which the current user has
one of the given local roles.
Let us look at an example of table:
+------+-----------------------------------------------+
| uid | allowedRolesAndUsers |
+------+-----------------------------------------------+
| 3331 | Assignee |
| 3331 | Assignor |
| 3331 | Associate |
| 3331 | Auditor |
| 3331 | Manager |
| 3331 | user:KNOWLEDGE-MANAGER_NXD-HQ-ONLINE |
| 3331 | user:KNOWLEDGE-MANAGER_NXD-HQ-ONLINE:Assignor |
| 3331 | user:NXD* |
| 3331 | user:NXD*:Auditor |
| 3331 | user:NXD-HQ-ONLINE |
| 3331 | user:NXD-HQ-ONLINE:Assignee |
| 3331 | user:NXD-HQ-ONLINE:Associate |
| 3331 | user:jp |
| 3331 | user:jp:Owner |
+------+-----------------------------------------------+
We can see 4 parts:
Global Role¶
| 3331 | Assignee |
This tells that the global role Assignee has View permission.
User¶
| 3331 | user:jp |
This tells that user jp has View permission.
Group¶
| 3331 | user:KNOWLEDGE-MANAGER_NXD-HQ-ONLINE |
This tells that group KNOWLEDGE-MANAGER_NXD-HQ-ONLINE has View permission.
Local Role¶
| 3331 | user:NXD-HQ-ONLINE:Assignee |
This tells that group NXD-HQ-ONLINE has local role Assignee in addition to having View permission.
| 3331 | user:jp:Owner |
This tells that user jp has local role Owner in addition to having View permission.
How can I make local role and View permission independent?¶
Sometimes, we would like to search for all documents which user jp can view and
for which user jp (or any of the security groups it is member of) has some local
role, for example Owner.
This means that jp may be allowed to View a document because it is member of
a group which has local role Assignee and because Assignee has View permission.
However, the local role Owner on the document does not give, alone, View
permission.
In this case, the roles_and_users table is useless (at least in its current
implementation).
The reason for this is that we have considered using local roles to filter
documents was only meaningful in combination with the View permission. It is
usually the case (and workflows should be designed with this constraint in mind).
However it is not always the case, especially with regard to the Owner role.
Searching for "My Documents" for which I am also one of the Assignee is not
possible with the roles_and_users table.
Two approaches can be recommended:
- create an extra table just to store local roles (multi valued)
- create an extra column just to store local role (single valued)
Optimisations¶
Two optimisations have been considered for the roles_and_users table. The goal was to reduce its size as much as possible.
Security UIDs¶
The first optimisation is to try to use the same uid value each time the list of roles and users were the same. This is the concept of security_uid. This approach is very
efficient in order to make sure all documents which share the same View permissions also share the same rows in the roles_and_users table. If well thought, this optimisation can
lead to a reduction of the roles_and_users table by a magnitude of 1000.
Single valued local roles¶
The second optimisation was to try to remove from roles_and_users certain roles which are known to be single valued and which tend to generate too many security_uid values.
For example, in a team of sales agent which share the same order portofolio with the same security settings, it is more efficient not to store the Owner local role in
roles_and_users. Storing it outside divides the size of roles_and_users by the number of users in the team. The idea was therefore to use a column in the catalog main table and to
create some cross indices to accelerate certain searches (ex. owner + portal_type in order accelerate "find all my Orders").
For example, our original table should look like this if the Owner role is stored in another column.
+------+-----------------------------------------------+
| uid | allowedRolesAndUsers |
+------+-----------------------------------------------+
| 3331 | Assignee |
| 3331 | Assignor |
| 3331 | Associate |
| 3331 | Auditor |
| 3331 | Manager |
| 3331 | user:KNOWLEDGE-MANAGER_NXD-HQ-ONLINE |
| 3331 | user:KNOWLEDGE-MANAGER_NXD-HQ-ONLINE:Assignor |
| 3331 | user:NXD* |
| 3331 | user:NXD*:Auditor |
| 3331 | user:NXD-HQ-ONLINE |
| 3331 | user:NXD-HQ-ONLINE:Assignee |
| 3331 | user:NXD-HQ-ONLINE:Associate |
+------+-----------------------------------------------+
Ignoring roles¶
Another approach, quite brutal, consists in ignoring certain local roles in the cataloging process.
Related Articles¶