Odoo User Access Rights | Configuration Guide

When you first install Odoo, the administrator account has access to everything. As you add employees, you must assign them to specific roles. Odoo's permission system is robust but can be confusing. It operates on three layers: Application Access (Can they open the Sales app?), Access Control Lists (Can they create a sales order or just read it?), and Record Rules (Can they see all sales orders or just their own?).

This guide is essential reading for system administrators and should be reviewed as part of your Post-Go-Live Hypercare and Multi-Company Setup.

Never give an employee more access than they need to do their job. 'Administrator' rights should be restricted to IT and top management.

Understanding Groups

In Odoo, permissions are tied to Groups, not directly to users. When you look at a User Profile, the dropdowns (e.g., Sales: "User: Own Documents Only", "User: All Documents", "Administrator") are actually assigning the user to different Groups under the hood.

Groups define what a user can see and do:

Menu Visibility: Does the "Configuration" menu appear for them?
Field Visibility: Can they see the "Cost" field on a product, or only the "Sales Price"?
Access Control Lists (ACL): The fundamental Read, Write, Create, and Delete permissions on database objects. A warehouse worker might have Read/Write access to inventory transfers but no Create/Delete access for new products.

Record Rules Explained

While ACLs define if a user can see a type of record, Record Rules define which specific records they can see.

Scenario

You have 10 sales reps. You want them to use the Sales app, but they should only see their own customers and their own orders.

Sales User: Own Documents

The Record Rule

A rule is applied to the Sales Order model: ['user_id', '=', user.id]. This filter is silently applied to every database query the user makes.

Record Rule Filter

The Result

Sales Rep A opens the Sales app and sees 50 orders. Sales Rep B opens the app and sees 30 different orders. The Sales Manager (who lacks this restricting rule) sees all 80 orders.

Secure Data Access

Developer Mode Configurations

To truly customize access rights, you must activate Developer Mode (Settings → General Settings → Activate the developer mode). This reveals the "Technical" menu under Settings.

Here you can create custom Groups. For example, if you want a "Junior Accountant" role that can create invoices but cannot post them, you would duplicate the standard Accountant group, modify the access rights on the Invoice model, and hide the "Post" button using an inherited view tied to your new group.

Multi-Company Security

If you run multiple companies in a single Odoo database, security becomes critical. Odoo handles this automatically if configured correctly.

Every record in Odoo (Products, Sales Orders, Invoices) has a `company_id` field. Users also have an "Allowed Companies" setting. A global record rule enforces that users can only see records where the `company_id` matches their currently active allowed companies. If a user is only allowed to see "Company A", they will never see "Company B's" invoices, even if they have full Accountant permissions.

Note · Manufacturing SME, SavarAudit reconciliation

To avoid "user can't do their job" tickets during a rushed go-live, the implementer gave every accounts staff member the full Accounting Administrator role. It worked smoothly — until a month-end reconciliation would not tie out. A junior staffer, who only ever needed to draft vendor bills, had used her Administrator access to post entries directly into a prior, already-closed period and had re-opened a bank reconciliation. None of it was malicious; she simply had buttons in front of her that her job never required. Untangling it took two days. We rebuilt her access as a custom "Junior Accounts" group — create and draft bills, but no posting rights and no period control. Over-permissioning rarely causes a dramatic breach; it causes quiet, expensive mistakes that surface months later in the numbers.

Bottom line

Before go-live, create "Test Users" for each major role (Test Salesperson, Test Warehouse Worker, Test Manager). Log in as these users and try to break the system or access forbidden data. This is the only way to guarantee your security model works. Need help auditing your system security? Get in touch →

Frequently asked questions

How does Odoo handle user permissions?

Odoo uses a combination of Application Roles (e.g., Sales: User vs Manager), Groups (which define what menus and fields a user sees), and Record Rules (which restrict which specific database rows a user can access, like 'only see my own sales orders').

What is Developer Mode in Odoo?

Developer Mode is a special setting that unlocks technical menus, allowing administrators to configure advanced access rights, record rules, and automated actions. It should only be used by trained administrators.

What is the principle of least privilege in Odoo?

Least privilege means every user gets exactly the access their job requires — and nothing more. In practice that means most staff sit on "User" roles rather than "Manager" or "Administrator", warehouse staff get inventory access but not accounting, and the Administrator role is reserved for IT and top management. The risk of over-permissioning is rarely a dramatic breach; it is quiet, accidental mistakes — a posted entry in a closed period, a changed cost price — that surface much later in the numbers.

How do I create a custom role like "Junior Accountant" in Odoo?

Activate Developer Mode, then under Settings → Technical → Groups duplicate the standard Accounting group as a starting point. Adjust the Access Control Lists so the new group can create and read invoices but not post them, and use an inherited view tied to the group to hide the "Post" button. Assign staff to this group instead of the full Accountant role. Always test it by logging in as a user with only the new group before go-live.