Two layers, often confused

Odoo controls access in two stages, and mixing them up is why permissions rarely work the way people expect.

Access rights answer: can this person open this app at all, and can they read, create, edit or delete in it?

Record rules answer: within what they can open, which specific records can they see?

The first is the door. The second is what is visible once you are inside.

Most real problems are in the second layer. Companies configure access rights carefully and leave record rules wide open, so a salesperson who should see their own accounts can see everybody’s.

Access rights

Permissions are granted through groups, not to individuals.

A user belongs to groups — Sales / User, Sales / Manager, Accounting / Billing — and each group carries a set of rights on a set of models.

Four separate permissions per model: read, create, edit, delete. They are independent, and that matters. Somebody can often read records they cannot edit, or create records they cannot delete.

Delete is worth restricting specifically. In most businesses very few people need it. Archiving keeps the record and removes it from view, which is almost always what people actually want.

Record rules

This is where the useful control lives.

A record rule is a condition applied to a group. Members of that group only see records matching it.

Common patterns:

Own records only. A salesperson sees opportunities where they are the salesperson.

Own team. A manager sees their whole team’s records.

One company. In a multi-company setup, users see only their company’s data.

One warehouse or branch. Staff see only their location.

Portal customers. Customers see only their own orders and invoices.

Two things to know:

Rules combine. A user in several groups may see the union of what each rule allows, which is not always what people expect. Test with a real login.

Administrator bypasses them. Anyone with administrator access sees everything, which is one reason to keep that group very small.

Testing them

Do not assume. Log in as the user.

Odoo lets an administrator impersonate a user in developer mode, or you can create a test account in the relevant group.

Then check:

• Can they see records they should not?
• Can they see everything they need to do their job?
• Can they delete something they should not?
• Do reports show only their own data?

That last one catches people out. Record rules apply to reports too, and a report that silently shows only part of the data can lead somebody to a wrong conclusion without any error appearing.

Portal users

Customers and suppliers with portal access are users too, with a heavily restricted set of rights.

Standard behaviour is that they see only their own records. Verify it rather than assuming — log in as a portal user and check.

And test it again after any custom development that touches portal-visible data. Custom code can accidentally bypass record rules, and portal data is the worst place for that to happen.

Multi-company

If you run more than one company in one database, this is where record rules do the heavy lifting.

Users are assigned to companies. Record rules keep each company’s data separate. Users with access to several can switch between them.

Get this right at setup. Untangling mixed company data afterwards is difficult and it affects your accounts, not just your screens.

And test it properly. Create a user in one company and confirm they cannot see the other’s customers, orders or figures.

The mistakes that recur

Five, and they appear in almost every unreviewed installation.

Everyone is an administrator. Set during implementation when everyone needed access to test, never tightened. Administrator can delete records, change valuation methods and export everything.

Record rules never configured. Access rights carefully set, record rules left open, so everybody sees everything within the apps they can reach.

Rules never tested with a real login. Configured, assumed correct, wrong.

Leavers still active. Deactivation should be part of your leaving process. Most companies find at least one when they check.

Shared logins. They destroy every audit trail Odoo keeps. You can see what was done and not who did it.

Custom modules and security

Worth knowing if you commission development.

A custom module can define its own access rights and record rules, and it can also bypass them — deliberately or by accident.

Two questions to ask a development partner:

What access rights does this module define, and which groups get them?

Does any of this code run with elevated privileges, and if so, why?

There are legitimate reasons for elevated code. There should be a stated reason, and somebody should have reviewed it.

A yearly review

It takes an afternoon and it is the single most useful security habit.

1. List every user and the groups they belong to
2. Go through it with whoever knows the roles
3. Remove access people no longer need
4. Deactivate anyone who has left
5. Count administrators — it should be one or two
6. Test one user per role with a real login

Roles drift. Somebody moves from sales to operations and keeps both sets of rights. Over three years several people accumulate far more access than their job needs, and nobody ever decided that.

The short version

Access rights decide which apps and models people can reach. Record rules decide which records they see within them.

Most problems are in the second layer, and most of those are because record rules were never configured or never tested.

Log in as a real user and check. Administrator bypasses the rules, so testing as administrator tells you nothing.

Keep administrator small, deactivate leavers, use individual logins, and review once a year.