Access rights and approval flows in Odoo

In most Odoo projects the crisis is not that the system cannot stop an action, but that nobody wrote the rule that says who owns the action and who approves it. Access rights are not a screen to be set in the final week before go-live; they are a management decision translated into groups, record rules and field restrictions. This article explains how security behaves in Odoo, what must be settled before go-live, and what should be tested with a real account rather than trusted from the configuration screen.

The three layers of security, and why a menu is not a right

Security in Odoo is three layers that intersect, and an action passes only when all three allow it:

• The user group and its access rights: a group grants the ability to read, create, write or delete a document type, and it is granted through groups rather than by user name.
• The record rule: it narrows the rows a user sees inside that same type — their own documents only, or their company's documents only.
• Field-level restriction: it prevents a user from reading or editing a specific field inside a record the user may already reach, such as a cost field, or salary data in the HR module.

The effective permission is the intersection of the layers: a user may hold the right to edit a vendor bill while a record rule limits visibility to their own company, and a field restriction stops them changing the cost. Any layer that is forgotten becomes a hole in the whole model.

Granting a menu is not granting a right. A menu is navigation, not a fence, and the model can be reached through a direct link, a report, an import or an API call. So the prohibition is built on access rights and record rules, while hiding a button stays interface polish, and a field removed from a form is still readable in reports and exports unless it is explicitly restricted. The right question is not whether the button appears but whether the user can perform the action by any route.

Multi-company and the common mistake

In a multi-company database every record carries a company field, and record rules alone confine visibility to the companies allowed for that user. The common mistake is to give access to every company during setup because it is easier; journal entries, invoices and stock moves then mix across legal entities, and the financial report of each company stops being reliable.

The decision is taken per role: which companies the user sees, in which company the user creates, and whether the role needs the company switcher in the top bar at all. Consolidated reading is built through the parent company or through specific reports, not by opening every company to every user. A user who sees two companies can create a record in the wrong one unless the create rule is constrained as well.

The decision matrix: role against action

Before touching the configuration screen, write a matrix that maps each role to each action, so configuration becomes translation rather than guesswork:

1. Write roles as they exist in the organisation structure, not as employee names, so the matrix does not break at any transfer or leave.
2. For each role, list the actions allowed on each document type: read, create, write, delete, approve.
3. Define the row scope of each action: all documents, company documents, or own documents only.
4. Define the sensitive fields forbidden to the role even when it owns the record, and write them down.
5. Translate the matrix into groups and record rules named so a reviewer understands them, not by internal codes.
6. Review it with the business owner and sign it off in writing; a permission the decision-maker does not know about is an invisible error.

Running without a matrix produces accumulated groups with opaque names, and every later change becomes a guess.

Double validation and approval tiers

An approval in Odoo is a state on the document, driven by a user, plus a group that determines who may move the document into that state. Double or tiered approval appears where the organisation separates recording from authorising: purchase orders above a defined threshold route to an additional approver, expense reports pass to a manager and then a designated approver, exceptional discounts require a supervisor's approval, and journal entries can be posted only by a defined accounting group, as reflected in the accounting configuration.

Where each is configured differs by case: approval limits are administered from the purchase and expense settings, the right to post an entry comes from access to the posting action, and the document state is what the system reads to decide whether a transition is allowed. Here the meaning must be plain: the system enforces the rule a human wrote and does not decide who should approve. If the rule says the requester's manager approves, the system will not check that this manager is the correct one, will not detect a conflict of interest, and will not judge whether the request deserves approval at all. It guards the door you drew, not the door you should have drawn.

The audit trail and the chatter

The chatter under a document is the record of what happened: messages, notifications and changes to tracked fields, with the user name and the date. But it lists only what was chosen for tracking, so the fields that must be tracked are decided before go-live, and history that was never logged cannot be recovered.

Shared logins destroy that record: when several people work under one account, approval loses its meaning because the system sees one approver and does not know who that is, and attributing an edit to a person becomes impossible. A personal account is a condition for anyone who creates, edits or approves, and temporary exceptions are documented and closed rather than left open.

Testing with a real account per role

The configuration screen describes intent; a real account reveals behaviour. Create an actual user per role, sign in as that user, and test the allowed action and the forbidden one together; a test that succeeds in showing the menu may still fail to forbid the action, and the value lies in confirming that the user cannot do what is not permitted, not that the button is absent.

Test reports, exports, imports, bulk actions and printed documents, not only forms, and test the approval path end to end: the request, the approval, the rejection, the absence of the approver, and editing after approval, keeping a written record per role. Anything not settled before go-live moves into support as a change request with its own estimate rather than a permission allowed by default.

In practice, permissions left to the final week before go-live are the most frequent cause of a delay, because they also push training, user acceptance testing and the closing that follows go-live. Access rights are, in the end, a distribution of responsibility: anyone who can post, approve or cancel should know that their name will appear against the action.

What we do not guarantee

• We do not guarantee a particular commercial outcome, and we do not tie project success to a figure announced in advance.
• We do not commit to a final price before analysing your scope, your modules and your data.
• We do not commit to a final duration before a written scope agreed by both parties; any timeline we mention remains a planning range.
• We issue no legal or tax opinion and no regulatory ruling; that remains your specialist adviser's responsibility.
• We grant no certificate, no accreditation and no official partner status to any party.
• We do not guarantee a search-engine ranking or an appearance in any particular result.