25 September 2026 · 3 min · Custom Odoo
Managing access rights by team in Odoo
In Odoo, access rights are organised by groups on four levels: which apps a user can open, which models they can read, create, edit or delete, which records they see (record rules), and which fields or buttons are shown to them. The right method starts from your teams’ real roles and relies as much as possible on standard groups. Here is how, with examples.
The four levels
- Apps: on the user form, each app offers levels — for Sales, “User: own documents only”, “User: all documents” or “Administrator”. Each level is a group.
- Models (access rights): for each model (quote, invoice, product…), a group may read, create, write, delete.
- Records (rules): record rules filter visible rows — a sales rep sees only their own quotes; in multi-company, users see only their companies’ data.
- Fields and buttons: a field or button can be restricted to certain groups — cost price, margin, “Cancel invoice”.
The 5-step method
- List roles: sales rep, sales assistant, warehouse, accountant, manager, management.
- Describe what each role must see and do, in a simple table.
- Map each role to Odoo’s standard groups: most needs are already covered.
- Add only what is missing: a group, a rule, a hidden field.
- Test with one account per role.
Example: a trading SME
| Role | Sales | Inventory | Invoicing | Specifics |
|---|---|---|---|---|
| Sales rep | Own quotes | Read | No | No cost price or margin |
| Sales assistant | All quotes | Read | Read | Can confirm orders |
| Warehouse | No | Full | No | No prices |
| Accountant | Read | Read | Full | — |
| Management | Full | Full | Full | Approves discounts above 15% |
The first columns are handled with standard groups. The last needs adjustments: hidden fields, an approval step.
Hiding fields and buttons
The most frequent request, and the least covered out of the box. Options: Odoo Studio in Enterprise; Ramira Studio — Access Rules in Community, to hide or lock fields, buttons, tabs and menus per group or user without code (see a Studio for Odoo Community); or a custom module that restricts fields in their definition. For truly sensitive data (salaries, margins), restrict at field or model level — something we set up in our custom modules.
Approvals and audit
Some actions should be controlled rather than forbidden: large discounts, purchases above an amount, credit notes. Our Approvals app requires sign-off before any button, in several steps; the Audit Log app records old and new values with restore. All apps are on our Odoo apps page.
Common mistakes
- Testing as administrator: the test proves nothing.
- Granting rights one by one instead of through groups.
- Creating dozens of custom groups instead of using the standard ones.
- Forgetting exports: a hidden field may still be exportable.
- Forgetting scheduled actions, which run with other rights.
To add team-specific information to records, see adding custom fields in Odoo; to adapt printed documents, customising Odoo invoices.
In short
Clear roles, standard groups, a few targeted rules and tests with real accounts: the key to a safe, simple Odoo. We do this in our Odoo configuration offer and in admin training. Write to us.
FAQ
Does the administrator see everything?
The superuser bypasses most rules. That is why you should never test rights with that account: log in with a test user for each profile.
Is hiding a field enough to protect it?
No. Hiding a field in a view prevents seeing it on screen, but not necessarily exporting or reading it another way. Real protection requires restricting the field by group in its definition, or rights on the model.
How many groups should I create?
As few as possible. Start from real roles (sales rep, warehouse, accountant, management) and reuse Odoo’s standard groups, adding only what is missing.
Sources
Mohamed Rahmouni — founder of Ramira, app developer and Odoo consultant in Niort, France. More