Understanding how the security system works in Odoo is crucial for effectively configuring user permissions and comprehending why certain data may or may not be visible to users within the system. This article provides an in-depth analysis of the security system in Odoo starting with users, groups, and element and data restrictions.
Users
To better understand the security system in Odoo, we can visualize it as a series of interconnected layers that collectively create a comprehensive security solution.
At the core of the security system is the user layer. Each user is a fundamental component that controls the level of access and privileges for a particular visitor. Every visitor to the system has a corresponding user profile. Visitors who are not logged in are typically assigned to the public user profile. The user's role in the system is defined within their profile, where can be assigned different types of security groups for the user.
A user can access the system by logging in using a standard username and password mechanism. Additionally, for enhanced security, a two-factor authentication process is available.
Groups
The next layer in the security system is known as "Groups," which serve as a bridge between users and the access limitations defined for specific application’s elements or data. Essentially, groups correspond to roles that can be assigned to employees within the system.
Groups in Odoo are structured in a hierarchical manner, which allows the nesting of multiple groups within one another. When a user is assigned to a particular group, they will inherit any related groups as well
For example, in the Sales module, there are three groups created for different levels of access. The first one, "Sales / User: Own Documents Only," is the lowest level and is designed for users with the lowest access rights. The second group, "Sales / User: All Documents," is intended to provide more broad access rights and includes the first group as an inherited group. Finally, the third group, "Sales / Administrator," has the most extensive permissions within the sales application and has the "Sales / User: All Documents" group as an inherited group.
- Sales / User: Own Documents Only
- Sales / User: All Documents
- Sales / Administrator
So If a user is assigned to the first group, "Sales / User: Own Documents Only," they will only have access to that group within the system. However, if they are assigned to the second group, "Sales / User: All Documents," they will automatically inherit the first group as well. Similarly, if a user is assigned to the third group, "Sales / Administrator," the system will automatically assign them to both the first and second groups.
If a group has inherited groups they can be found in the "Inherited" tab of the group’s form view. Within the group form view, also can be found any related menus, views, access rights or record rules assigned to the group as well as any related users. This information can help to understand the level of security access that the group has in the system.
In Odoo, every group can be assigned to multiple users, and conversely, one user can be assigned to multiple groups which allows for flexible management of access rights.
Element Restrictions
Groups are an essential part of the access control system, but they cannot act on their own. They need to be linked to a component in the next layer to fully exercise their power. This layer contains two types of restrictions:
- Element restrictions
- Data restrictions
They are designed to limit users' access to specific elements and data in the system.
Element restrictions are mainly defined in the codebase and can limit the view of buttons, fields, menus, and even entire views can be assigned to a group. This means that only users who are members of the particular group will be able to see that element. For example, only "Sales / Administrator" group may be able to view “Unlock” button in the Sales form view or the “Reporting” menu in the Sales application. Although these types of restrictions are usually defined in the codebase, they can be set from the UI as well, in the menus and views sections.
Data Restrictions
The second type of restriction is related to data models and is used to limit the user access to only the data that they have been granted permission to view, based on their assigned access groups. This type of restriction involves two layers of data control:
- Access Rights
- Record Rules.
Access Rights
Access Rights are responsible for the general control of the data stored in the data model. They define whether a user can read/write/create or delete the data related to that model. When defining access rights, it is enough to use the lowest level group, which will then be inherited by other groups. This means that other groups will also have the same access rights.
For instance, users with groups "Sales/Administrator" and "Sales/User: Own Documents Only" will both have the rights to read, create, write, and delete although the access rights are defined only for "Sales/User: Own Documents Only". However, if we take a look into the access rights defined for the “Public” group we can see that most of them have only read permissions because the group is expected to have minimal permissions in the system.
It is crucial to define access rights for each data model and assign appropriate groups to each. While it is possible to define access rights without a group, it is not recommended, especially for models holding sensitive data, as it would make the data accessible to anyone without any restrictions. It is always best to assign a group to every access right and give the minimum required rights.
Record Rules
While Access Rights are applied as a general rule for the entire data in the model, Record Rules filter the data at a more granular level. The Record Rules layer is designed to filter the data in the model based on predefined filters and to show only what a user should be able to see.
For example, let's consider the Sales groups again. A user with the group "Sales/User: Own Documents Only" can only see the sales orders where it is assigned as a salesperson, while a user with the group "Sales/User: All Documents" can see all sales orders in the system. To achieve this, there are two record rules defined.
The first rule is "Personal Orders," which is assigned to the "Sales/User: Own Documents Only" group. The domain in this rule is defined in such a way that records are filtered by the user who is assigned as a salesperson to the order. So the user can see only the orders to which they are assigned as a salesperson as well as all orders with an undefined salesperson.
The second rule is "All Orders," and as the name suggests, nothing is filtered from the records, so all orders can be seen by the users with the "Sales/User: All Documents" group.
Record Rules also have the option to limit different permissions, such as read, create, write, and delete. There may be cases where a user has the right to see the order but cannot perform any other actions on it. For example, “Portal” users can see their own orders, can edit them and remove them but they can not create a new order, so the order needs to be created for them by another user in the system.
If a group is not assigned to a rule, then the rule is considered a global rule and applies to all users. Global rules are mainly used to restrict data between different companies. For example, in the "Sales Order multi-company" rule, users can only see the orders created for the companies they are assigned to.
It is important to understand that global record rules are strict restrictions and cannot be overridden. On the other hand, record rules assigned to groups can further restrict global rules but can also be relaxed by additional group rules. This means that for a user to see a record, all global rules must be met, while for rules assigned to a group, at least one of the rules needs to be met. So, Record Rules apply to all users in that group, but can be extended by additional rules assigned to different groups.
Returning to the Sales example, users with the "Sales / User: All Documents" group can see all documents, despite also having the "Sales / User: Own Documents Only" group, because the record rule "All Orders" extends the rule "Personal Orders" with an additional domain that allows viewing all orders in the system.
Conclusion
Every visitor is assigned to a user who is assigned to access groups that are related to both element and data restrictions. Element restrictions control what elements the user can see, such as buttons, fields, views, and menus, while data restrictions limit what data the user can access in the system. There are two layers of data control: Access Rights and Record Rules. Access Rights are responsible for general data control in the data model, while Record Rules filter data at a more granular level.
If a group is not assigned to a rule, the rule is considered a global rule and applies to all users. Global record rules are strict and cannot be overridden, while record rules assigned to groups can further restrict global rules but can also be relaxed by additional group rules.