What Is Odoo Security and Why It Matters

Odoo security controls who can see, create, edit, and delete data in your system. Without proper security configuration, users may access sensitive information they shouldn't see or accidentally modify critical records.
TL;DR: What You Need to Know
- Native integration: Everything works within Odoo: no third-party tools required
- Quick setup: Follow the step-by-step guide to configure in under 30 minutes
- Full tracking: Monitor results with built-in analytics and reporting
Proper security setup prevents:
- Sales reps viewing competitor pricing or cost margins
- Warehouse staff modifying financial records
- Junior users deleting important customer data
- Cross-department visibility of confidential information
This guide covers the three pillars of Odoo security: access rights (what you can do), groups (how you organize users), and record rules (which records you can see).
Understanding Odoo's Security Model
Odoo uses a layered security approach with four components working together:
1. Users
Each person gets a user account with an email address. Users belong to groups and inherit their permissions.
2. Groups
Groups define collections of access rights. Users in a group get all its permissions. Groups can inherit from other groups (e.g., Manager inherits from User).
3. Access Rights (ACL)
Access Control Lists define CRUD permissions (Create, Read, Update, Delete) on each model. For example, "Sales User can read and create quotations but not delete them."
4. Record Rules
Record rules filter which specific records a user can access. For example, "Sales reps see only their own quotations" even if they have read access to all quotations.
Configuring Access Rights
Access rights are defined per model in CSV files or through the interface. Each row specifies permissions for a group on a specific model.
Access Rights CSV Format
Odoo stores access rights in ir.model.access.csv files with these columns:
| Field | Description | Example |
|---|---|---|
id |
Unique XML ID | access_sale_order_user |
model_id:id |
Model reference | model_sale_order |
group_id:id |
Group reference | sales_team.group_sale_salesman |
perm_read |
Read permission (0/1) | 1 |
perm_write |
Write permission (0/1) | 1 |
perm_create |
Create permission (0/1) | 1 |
perm_unlink |
Delete permission (0/1) | 0 |
Example: Sales Order Access

id,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink access_sale_order_user,model_sale_order,sales_team.group_sale_salesman,1,1,1,0 access_sale_order_manager,model_sale_order,sales_team.group_sale_manager,1,1,1,1
This configuration allows sales users to read, write, and create orders but not delete them. Managers have full permissions including deletion.
Viewing Access Rights in the Interface
Navigate to Settings > Users & Companies > Groups to see all groups and their permissions. Enable Developer Mode to access detailed configuration.
Creating and Managing Security Groups
Groups organize users by role and define their baseline permissions. Odoo comes with predefined groups for each application.
Default Sales Groups
- Sales User: Own Documents Only - Can see and edit only their own quotations and orders
- Sales User: All Documents - Can see and edit all quotations and orders
- Sales Manager - Full access plus configuration and team management
Creating a Custom Group
Example: Create a "Junior Sales Rep" group with limited permissions:
- Enable Developer Mode (Settings > scroll down > Activate Developer Mode)
- Go to Settings > Users & Companies > Groups
- Click Create
- Name: "Junior Sales Rep"
- Application: Select "Sales"
- Inherited Groups: Add "Sales User: Own Documents Only"
- Save
Group Inheritance
Groups can inherit from other groups, accumulating permissions. This creates a hierarchy:
- Internal User (base level) → Sales User → Sales Manager
- Each level adds more permissions
- Users can belong to multiple groups (permissions combine)
Implementing Record Rules
Record rules filter which specific records users can access, even if they have model-level read permissions.
When to Use Record Rules
Use record rules when you need to restrict access based on:
- Ownership - Users see only records they created
- Team membership - Users see records for their sales team
- Company - Multi-company setups restrict data per company
- Document state - Draft documents visible only to authors
Record Rule Domain Syntax

Record rules use Odoo domain expressions (Python-like tuples):
# User sees only their own records
[('user_id', '=', user.id)]
# User sees records from their sales team
[('team_id', '=', user.sale_team_id.id)]
# User sees records from their company
[('company_id', 'in', company_ids)]
# User sees draft records they own OR all confirmed records
['|', ('state', '=', 'draft'), ('user_id', '=', user.id), ('state', 'in', ['sale', 'done'])]
Creating a Record Rule
Example: Restrict sales reps to their own quotations:
- Go to Settings > Technical > Security > Record Rules
- Click Create
- Name: "Sales User: Own Quotations Only"
- Model: "Quotation / Order" (sale.order)
- Apply for Read: ✓
- Apply for Write: ✓
- Apply for Create: ✓
- Apply for Delete: ✗
- Groups: Add "Sales User: Own Documents Only"
- Domain:
[('user_id', '=', user.id)] - Save
Testing Record Rules
Always test record rules with different user accounts:
- Create a test user in the target group
- Log in as that user (or use "Log in as" in Developer Mode)
- Verify they see only expected records
- Try accessing a restricted record directly via URL
Multi-Company Security
Odoo's multi-company feature adds another security layer. Users can be assigned to one or multiple companies.
Company Assignment
- Allowed Companies - Companies the user can access
- Current Company - The company the user is working in (switchable)
Company-Based Record Rules
Most Odoo models include a company_id field. Default record rules restrict access:
# Default multi-company rule
['|', ('company_id', '=', False), ('company_id', 'in', company_ids)]
This allows users to see:
- Records with no company set (shared across all companies)
- Records from their assigned companies
Best Practices for Multi-Company
- Assign users only to companies they need
- Use company-specific groups when permissions differ by company
- Test cross-company access thoroughly
- Be careful with shared data (products, customers) - set company to blank if truly shared
Security Audit and Troubleshooting
Checking User Permissions

In Developer Mode, go to any record and click the bug icon > "View Metadata" to see access information:
- Which groups the current user belongs to
- Whether they have read/write/create/delete access
- Which record rules apply
Common Security Issues
Issue: User Can't See Expected Records
Diagnosis:
- Check user's groups (Settings > Users > select user)
- Check access rights for the model (Settings > Technical > Security > Access Rights)
- Check record rules (Settings > Technical > Security > Record Rules)
- Verify company assignment matches record's company
Issue: User Can See Records They Shouldn't
Diagnosis:
- Check if user belongs to multiple groups (permissions combine)
- Look for overly permissive record rules (domain always evaluates to True)
- Check for manager-level groups that override restrictions
Issue: Access Error When Creating Records
Diagnosis:
- Check perm_create in access rights CSV
- Verify record rule allows creation (domain must be satisfiable)
- Check if required fields are hidden by view-level restrictions
Security Best Practices
Principle of Least Privilege
Start with minimal permissions and add only what's needed:
- Assign users to the most restrictive group that allows them to work
- Use "Own Documents Only" groups for junior staff
- Reserve "All Documents" and Manager groups for supervisors
- Review permissions quarterly
Regular Security Audits
Schedule quarterly reviews:
- List all users and their groups
- Identify inactive users (disable or archive)
- Review custom record rules for conflicts
- Test critical restrictions with test accounts
Developer Mode Caution

Developer Mode bypasses some restrictions. Never leave it enabled for regular users:
- Enable only when troubleshooting
- Disable immediately after use
- Never grant administrator access to regular users
Conclusion
Odoo security requires understanding four components: users, groups, access rights, and record rules. Proper configuration protects sensitive data while enabling users to work efficiently.
Key takeaways:
- Access rights control CRUD operations on models
- Groups organize users and accumulate permissions through inheritance
- Record rules filter which specific records users can access
- Multi-company adds another layer of data isolation
- Always test security with actual user accounts
Start with Odoo's default groups, customize only when necessary, and audit permissions regularly to maintain a secure system.
Summary
Odoo security combines access rights (CRUD permissions), groups (permission collections), and record rules (data filters) to control user access. Configure groups based on job roles, apply the principle of least privilege, and test thoroughly with real user accounts. Regular security audits ensure permissions remain appropriate as your team grows.
Frequently Asked Questions
How do I give a user read-only access to sales orders?
Create a custom group with access rights CSV: perm_read=1, perm_write=0, perm_create=0, perm_unlink=0. Assign the user to this group. Add a record rule if you need to restrict which specific orders they can see.
Can a user belong to multiple groups?
Yes, users can belong to multiple groups. Permissions accumulate across all groups - the user gets the union of all permissions. Be careful not to accidentally grant elevated access through group combinations.
What's the difference between access rights and record rules?
Access rights control whether you can perform actions (read, write, create, delete) on a model. Record rules control which specific records you can access. You need both: access rights to touch the model at all, and record rules to filter which records within that model.
How do I hide a field from certain users?
Use view inheritance with groups attribute. In the view XML, add groups="your_module.group_name" to the field element. Users not in that group won't see the field. This is view-level security, separate from access rights.
Why can't users see records they created last week?
Check record rules - there may be a rule filtering by date, state, or team membership. Also verify the user's company assignment hasn't changed. Use Developer Mode to inspect which record rules apply to the model.
Take Your Odoo to the Next Level
Learn best practices and get expert guidance for implementing this feature in your Odoo instance.
References
- Odoo Documentation: "Security" (2026). https://www.odoo.com/documentation/18.0/developer/reference/backend/security.html
- Odoo Documentation: "Groups and Access Rights" (2026). https://www.odoo.com/documentation/18.0/applications/general/users/access_rights.html
- Odoo Documentation: "Record Rules" (2026). https://www.odoo.com/documentation/18.0/developer/reference/backend/orm.html
- Odoo Community Association: "Security Best Practices" (2025). https://github.com/OCA/odoo-community.org
- Cybrosys Technologies: "Odoo Access Rights and Record Rules Explained" (2025). https://www.cybrosys.com/blog/odoo-access-rights-and-record-rules