Two different questions

Security in Odoo comes down to two things people often mix up.

Access rights — which models a user can read, create, edit or delete. Can this person open the accounting app at all?

Record rules — which specific records within a model they can see. Can this salesperson see every customer, or only their own?

Access rights are the door. Record rules are what is visible once you are inside.

Most real-world problems come from the second being left wide open while everyone worries about the first.

Groups, not individuals

Odoo assigns permissions through groups, not per person.

A user belongs to groups — Sales / User, Accounting / Billing, Inventory / Manager — and each group carries a set of rights. Add someone to the group and they inherit them.

This is the right approach, and it means the important question is not “what can Priya do?” but “what should a salesperson be able to do?”

Define it once, per role. Then adding a new person is a two-minute job rather than a series of guesses.

The mistakes that recur

Five patterns, seen in almost every unreviewed installation.

Everyone is an administrator

The most common and the most serious.

It usually starts reasonably — during implementation, everyone needs broad access to test. Then it never gets tightened.

Administrator access can delete records, change accounting settings, alter valuation methods and export everything. In a small company that trusts its people, this still matters: it is one mistaken click away from a problem nobody can explain later.

Administrator should be one or two people. Everyone else gets the rights their role needs.

People who left still have access

Deactivating accounts should be part of your leaving process, not something remembered months later.

Check this now. Most companies find at least one.

Nobody reviews it

Roles change. Someone moves from sales to operations and keeps both sets of rights. Over three years, several people end up with far more access than their job needs.

A yearly review is enough. Print the user list with their groups, and go through it with whoever knows the roles.

Shared logins

One account used by several people. It defeats every audit trail Odoo keeps — you can see what was done, but not by whom.

Individual accounts, always.

The master password

The database master password controls creating, dropping and restoring databases. It is not a normal user login.

It should not be the default, it should be strong, and it should be known by very few people.

Two-factor authentication

Odoo supports two-factor authentication, and it is worth enabling — particularly for anyone with administrator or accounting access.

A leaked password stops being enough on its own. Given how many breaches begin with a reused password, this is one of the highest-value security settings available.

One thing to know: integrations using a password will break when 2FA is enabled on that account. Use API keys for integrations instead. They are designed for exactly this, and they can be revoked individually.

Portal users

If you give customers or suppliers portal access, they are users too — with a restricted set of rights.

Two things to verify:

They see only their own records. This is standard behaviour, and it is worth testing rather than assuming. Log in as a portal user and check.

Custom modules respect it. Custom code can accidentally bypass record rules. Any custom development touching portal-visible data should be tested from a portal login.

The audit trail

Odoo records who created and last modified each record, and the chatter on each document keeps a history of changes and messages.

Two practical points:

It only works if logins are individual. Shared accounts make the trail meaningless.

Deleting removes the record. Archiving keeps it. Where history matters, prefer archiving and restrict who can delete.

For accounting specifically, posted entries cannot be edited — corrections are made through credit notes and reversals. That is not Odoo being awkward; it is what makes the books auditable.

Practical hygiene

Six things, none of them complicated.

• Individual accounts for everyone
• Administrator limited to one or two people
• Two-factor authentication on privileged accounts
• API keys for integrations, never a person’s password
• Deactivation as part of the leaving process
• A yearly review of who is in which group

If you host it yourself

Self-hosting adds a layer that is nobody’s job until it is.

Security patches for the operating system and for Odoo itself need applying. This is routine work that stops being routine when it is skipped for a year.

HTTPS should be in place and its certificate kept valid.

Backups need to be off-server and tested — ransomware that reaches your server will reach backups stored on it.

Database access should not be reachable from the open internet.

If nobody in your company owns this list, that is a genuine argument for hosted Odoo. The licence saving is smaller than the cost of the incident you eventually have.

The short version

Odoo’s security model is capable. Most real problems are not gaps in the software — they are permissions that drifted and were never reviewed.

Define rights per role. Keep administrator small. Deactivate leavers. Review once a year.

That covers most of it.