Security in Odoo comes down to two things people often mix up.<\/p>\n
Access rights<\/strong> \u2014 which models a user can read, create, edit or delete. Can this person open the accounting app at all?<\/p>\n Record rules<\/strong> \u2014 which specific records within a model they can see. Can this salesperson see every customer, or only their own?<\/p>\n Access rights are the door. Record rules are what is visible once you are inside.<\/p>\n Most real-world problems come from the second being left wide open while everyone worries about the first.<\/p>\n FIGURE 1: THE TWO LAYERS THAT CONTROL ACCESS<\/p>\n Access rights<\/p>\n Record rules<\/p>\n Odoo assigns permissions through groups<\/strong>, not per person.<\/p>\n A user belongs to groups \u2014 Sales \/ User, Accounting \/ Billing, Inventory \/ Manager \u2014 and each group carries a set of rights. Add someone to the group and they inherit them.<\/p>\n 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?”<\/strong><\/p>\n Define it once, per role. Then adding a new person is a two-minute job rather than a series of guesses.<\/p>\n Five patterns, seen in almost every unreviewed installation.<\/p>\n The most common and the most serious.<\/p>\n It usually starts reasonably \u2014 during implementation, everyone needs broad access to test. Then it never gets tightened.<\/p>\n 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.<\/p>\n Administrator should be one or two people.<\/strong> Everyone else gets the rights their role needs.<\/p>\n Deactivating accounts should be part of your leaving process, not something remembered months later.<\/p>\n Check this now. Most companies find at least one.<\/p>\n 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.<\/p>\n A yearly review is enough.<\/strong> Print the user list with their groups, and go through it with whoever knows the roles.<\/p>\n One account used by several people. It defeats every audit trail Odoo keeps \u2014 you can see what was done, but not by whom.<\/p>\n Individual accounts, always.<\/p>\n The database master password controls creating, dropping and restoring databases. It is not a normal user login.<\/p>\n It should not be the default, it should be strong, and it should be known by very few people.<\/p>\n FIGURE 2: FIVE GAPS TO CHECK THIS WEEK<\/p>\n Administrator access<\/p>\n Leavers<\/p>\n Shared logins<\/p>\n Role drift<\/p>\n Master password<\/p>\n Odoo supports two-factor authentication<\/strong>, and it is worth enabling \u2014 particularly for anyone with administrator or accounting access.<\/p>\n 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.<\/p>\n One thing to know:<\/strong> integrations using a password will break when 2FA is enabled on that account. Use API keys<\/strong> for integrations instead. They are designed for exactly this, and they can be revoked individually.<\/p>\n If you give customers or suppliers portal access, they are users too \u2014 with a restricted set of rights.<\/p>\n Two things to verify:<\/p>\n They see only their own records.<\/strong> This is standard behaviour, and it is worth testing rather than assuming. Log in as a portal user and check.<\/p>\n Custom modules respect it.<\/strong> Custom code can accidentally bypass record rules. Any custom development touching portal-visible data should be tested from a portal login.<\/p>\n Odoo records who created and last modified each record, and the chatter on each document keeps a history of changes and messages.<\/p>\n Two practical points:<\/p>\n It only works if logins are individual.<\/strong> Shared accounts make the trail meaningless.<\/p>\n Deleting removes the record.<\/strong> Archiving keeps it. Where history matters, prefer archiving and restrict who can delete.<\/p>\n For accounting specifically, posted entries cannot be edited \u2014 corrections are made through credit notes and reversals. That is not Odoo being awkward; it is what makes the books auditable.<\/p>\n Six things, none of them complicated.<\/p>\n FIGURE 3: TWO WAYS AN ODOO SYSTEM CAN LOOK<\/p>\n Well controlled<\/p>\n Drifted over time<\/p>\n Self-hosting adds a layer that is nobody’s job until it is.<\/p>\n Security patches<\/strong> 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.<\/p>\n HTTPS<\/strong> should be in place and its certificate kept valid.<\/p>\n Backups<\/strong> need to be off-server and tested \u2014 ransomware that reaches your server will reach backups stored on it.<\/p>\n Database access<\/strong> should not be reachable from the open internet.<\/p>\n 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.<\/p>\n Odoo’s security model is capable. Most real problems are not gaps in the software \u2014 they are permissions that drifted and were never reviewed.<\/p>\n Define rights per role. Keep administrator small. Deactivate leavers. Review once a year.<\/strong><\/p>\n That covers most of it.<\/p>\n Not sure who can see what in your Odoo?<\/p>\n Get in touch. We will review your groups, record rules and user list, and tell you plainly where the gaps are.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Two different questions Security in Odoo comes down to two things people often mix up. Access rights \u2014 which models a user can read, create, edit or delete. Can this person open the accounting app at all? Record rules \u2014 which specific records within a model they can see. Can this salesperson see every customer, […]<\/p>\n","protected":false},"author":3,"featured_media":9092,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9091","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\n\n
\n
Groups, not individuals<\/h2>\n
The mistakes that recur<\/h2>\n
Everyone is an administrator<\/h3>\n
People who left still have access<\/h3>\n
Nobody reviews it<\/h3>\n
Shared logins<\/h3>\n
The master password<\/h3>\n
\n
\n
\n
\n
\n
Two-factor authentication<\/h2>\n
Portal users<\/h2>\n
The audit trail<\/h2>\n
Practical hygiene<\/h2>\n
\n
\n
\n
If you host it yourself<\/h2>\n
The short version<\/h2>\n