When implementing an ERP system like Odoo 18, security and access control are among the most critical aspects of system design. A well-configured system not only ensures smooth operations but also protects company data and prevents unauthorized access.
In this article, we’ll dive deep into how User Roles, Access Rights, and Security Rules work in Odoo 18 — from core concepts to technical implementation.
🔑 1. What Are User Roles in Odoo?
User Roles (or User Groups) in Odoo define what a user can or cannot do in the system.
They are the foundation of Odoo’s security model, grouping users according to their responsibilities and permissions.
Common Examples of User Roles
Role | Description |
Administrator | Full access to all modules and settings. |
Manager | Can view, create, and manage data within their department. |
User | Limited access, usually to records they own. |
Portal User / Public User | External users (e.g., customers accessing the portal). |
You can manage user groups via:
Settings → Users & Companies → Groups
Each group is linked to specific models and determines what operations users are allowed to perform.
⚙️ 2. Access Rights (Model-Level Security)
Access Rights in Odoo define what type of operations a user can perform on a specific model (database table).
They are defined using an Access Control List (ACL), typically in a CSV file located under your module’s security/ directory.
Example: security/ir.model.access.csv
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_employee_user,employee_user,model_hr_employee,base.group_user,1,0,0,0
access_employee_manager,employee_manager,model_hr_employee,base.group_hr_manager,1,1,1,1
Field Explanation:
- model_id → The model (table) the access applies to.
- group_id → The user group that gets the permission.
- perm_read → Permission to read records.
- perm_write → Permission to modify existing records.
- perm_create → Permission to create new records.
- perm_unlink → Permission to delete records.
By defining these rules, you can control exactly which users can modify or delete sensitive information.
🧩 3. Record Rules (Record-Level Security)
While Access Rights control permissions at the model level, Record Rules control access at the record level — meaning they can restrict which records a user can see, modify, or delete.
Example Record Rule (security/sale_order_rule.xml)
<record id="sale_order_rule_user" model="ir.rule">
<field name="name">Salesperson: See only own orders</field>
<field name="model_id" ref="sale.model_sale_order"/>
<field name="domain_force">[('user_id', '=', user.id)]</field>
<field name="groups" eval="[(4, ref('sales_team.group_sale_salesman'))]"/>
</record>
Explanation:
- domain_force → Defines the domain (filter) applied to record access.
- user.id → Refers to the currently logged-in user.
- groups → Defines which user group the rule applies to.
This ensures that, for example, salespeople can only see their own sales orders — not those of other team members.
🧠 4. How Odoo Applies Security Rules
Odoo enforces security through a hierarchy of checks.
Whenever a user tries to access data, Odoo evaluates permissions in the following order:
- Record Rules (record-level domain filters)
- Access Control Lists (ACLs)
- User Group Membership
- User Access Level (e.g., portal, internal, admin)
If any rule denies access, Odoo immediately raises a security exception — preventing unauthorized data exposure.
🔐 5. How to Define Security in Custom Modules
Every Odoo module that introduces new models should define its own security configuration.
A typical structure looks like this:
your_module/
├── security/
│ ├── ir.model.access.csv
│ └── your_module_security.xml
├── models/
│ └── your_model.py
└── __manifest__.py
Step 1. Create Access Control List (ACL)
security/ir.model.access.csv
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_project_user,project_user,model_project_task,base.group_user,1,1,1,0
Step 2. Add Record Rule
security/your_module_security.xml
<odoo>
<record id="task_rule_user" model="ir.rule">
<field name="name">User can only see own tasks</field>
<field name="model_id" ref="project.model_project_task"/>
<field name="domain_force">[('user_id', '=', user.id)]</field>
<field name="groups" eval="[(4, ref('base.group_user'))]"/>
</record>
</odoo>
Step 3. Add Security Files to Manifest
__manifest__.py
'data': [
'security/ir.model.access.csv',
'security/your_module_security.xml',
],
🧩 6. Implied Groups (Group Hierarchy)
In Odoo, groups can inherit the permissions of other groups using the implied_group feature.
This allows you to define hierarchies between roles — e.g., a “Manager” automatically gets all permissions of a “User”.
Example in Python:
class ResConfigSettings(models.TransientModel):
_inherit = 'res.config.settings'
group_manager = fields.Many2one(
'res.groups',
string='Manager Group',
implied_group='your_module.group_user',
)
So when a user is assigned to group_manager, they automatically inherit all access rights of group_user.
⚠️ 7. Common Mistakes and How to Avoid Them
❌ Overlapping record rules
→ Two conflicting domains can cause users to lose access to data entirely.
✅ Always test your record rules using multiple test users.
❌ Missing ACLs for custom models
→ Odoo will block access by default if no ACL is defined.
✅ Always create at least one basic ACL for each new model.
❌ Giving too much access to groups
→ Adding a group like base.group_system or base.group_erp_manager can expose sensitive data.
✅ Assign admin-level groups only when absolutely necessary.
❌ Bypassing ORM checks
→ Direct SQL queries skip Odoo’s security layer.
✅ Always use Odoo’s ORM methods (search(), create(), write(), unlink()) to enforce security automatically.
🧩 8. Debugging Security Issues
When users face “Access Error” or “Record Rule Error”, you can debug it by:
- Activating Developer Mode
- Going to Settings → Technical → Security → Access Rights / Record Rules
- Checking which rule or group is restricting access
You can also check from code:
self.env.user.has_group('module_name.group_manager')
This returns True if the logged-in user belongs to that group.
💡 9. Security Best Practices for Odoo 18
Here are some best practices to follow:
- ✅ Separate access levels clearly — create distinct groups (e.g., user, manager, admin).
- ✅ Always define at least one ACL for every new model.
- ✅ Keep Record Rules simple and efficient.
- ✅ Test access with real users — not only as admin.
- ✅ Avoid using sudo() carelessly — it bypasses security rules.
- ✅ Regularly review your group hierarchy using the Developer Mode
Conclusion
Security in Odoo 18 is not just about restricting users — it’s about ensuring that everyone has the right access at the right level.
By mastering User Roles, Access Rights, and Record Rules, you can build an Odoo system that is secure, scalable, and compliant with best practices.
Whether you’re a developer building a custom module or a functional consultant setting up permissions, understanding these layers of Odoo security is essential for a stable and secure ERP implementation.