The ability to control who has access to certain information and who is allowed to manipulate it is one of the main features of an enterprise resource planning solution. Rather than permitting every individual user account, Odoo uses Group-Based Access Control Lists (ACLs).
Odoo does not give "John Doe" permission to create an invoice. What Odoo does is give the "Accounting / Accountant" group permission to create invoices and add "John Doe" to the group. This allows the database to remain tidy, users to be easily onboarded, and virtually eliminates security problems caused by changes in employee roles.
Here is an explanation of Group-Based ACL in Odoo from a system administrator's perspective and from a developer's technical perspective.
Functional Approach: Working with ACLs Using UI
System Administrators create and manage user and permission groups using the Odoo back-end interface. However, before working with the most advanced security configurations, you have to turn on Developer Mode.
- Creating and Managing Groups: Go to Settings > Users and companies > Groups. In this menu, you will see all the security groups in your database (for example, Sales/ Administrator, Inventory/User). Within a particular group configuration, you can perform actions like:
- Add or remove users in the "Users" tab.
- Assign particular menus and views that should be available for users of this group only.
- See the particular rights to model access (Read, Write, Create, Delete) assigned to this group.
- Implied Groups (Inheritance): Odoo widely uses group inheritance to save time. In group settings, there is an "Inherited" tab, which indicates that a higher-level group will inherit the permissions of the lower-level group. If you put a person into the Sales/ Administrator group, they will automatically inherit the rights of the Sales/ User: All documents group. No need to add them to both.
The Technical Perspective: ACL Implementation Through Coding
Whenever developers develop a custom module, they need to configure the access rules in the security folder of the custom module. Without such security configurations, non-administrative users will have Access Error alerts.
There are basically three security components in Odoo that involve res.groups:
1. The definition of the Group in XML (res.groups): In the first step, the group is defined in the XML Security configuration file, and also a category for categorizing it in the UI settings of the user.
The Odoo 19 version does not have the category_id field on the res.groups model. Rather, the res.groups model has the privilege_id field, whereas the category_id field belongs to the res.groups.privilege model.
<odoo>
<record id="module_category_my_module" model="ir.module.category">
<field name="name">My Module</field>
<field name="description">Helps you manage My Module access rights</field>
<field name="sequence">25</field>
</record>
<record id="my_module_privilege" model="res.groups.privilege">
<field name="name">My Module</field>
<field name="category_id" ref="module_category_my_module"/>
</record>
<record id="group_my_module_user" model="res.groups">
<field name="name">User</field>
<field name="privilege_id" ref="my_module_privilege"/>
</record>
<record id="group_my_module_manager" model="res.groups">
<field name="name">Manager</field>
<field name="privilege_id" ref="my_module_privilege"/>
<field name="implied_ids" eval="[Command.link(ref('group_my_module_user'))]"/>
<field name="comment">Full access to My Module, including configuration.</field>
</record>
</odoo>
2. Table-level permissions: ir.model.access.csv. After defining the user group, the next step is to specify which database tables (models) it will be able to use. The information is presented in ir.model.access.csv. Here, the relationship between the model and the group is established using binary logic (True - 1, False - 0) for four actions – Reading, Writing, Creating, and Deleting.
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_custom_model_user,custom.model.user,model_custom_model,group_custom_user,1,1,1,0
In this case, members of group_custom_user will be able to view, write, and create data in the custom.model table, but will not be allowed to delete it.
3. Row-level permissions: Record rules (ir.rule) Whereas ir.model.access.csv denies access to an entire table, record rules deny access to particular rows within that table depending on certain criteria. For example, you may want salespeople to access the Sales Order table but only view their orders.
<record id="rule_personal_orders" model="ir.rule">
<field name="name">Personal Orders Only</field>
<field name="model_id" ref="model_sale_order"/>
<field name="groups" eval="[(4, ref('sales_team.group_sale_salesman'))]"/>
<field name="domain_force">[('user_id', '=', user.id)]</field>
</record>
Take note of the groups field, there is an explicit link between our record rules and group-based ACL architecture.
Odoo’s group-based security model closes the divide between limitations posed by backend programming and administration in the frontend interface. With the use of ir.model.access to define base access permissions, ir.rule to define custom filtering, and group inheritance to simplify security configuration, technical and functional departments can create a highly secured and flexible ERP solution.
To read more about Best Practices for Access Control Lists (ACLs) in Odoo, refer to our blog Best Practices for Access Control Lists (ACLs) in Odoo.