Odoo controls access in two stages, and mixing them up is why permissions rarely work the way people expect.<\/p>\n
Access rights<\/strong> answer: can this person open this app at all, and can they read, create, edit or delete in it?<\/em><\/p>\n Record rules<\/strong> answer: within what they can open, which specific records can they see?<\/em><\/p>\n The first is the door. The second is what is visible once you are inside.<\/p>\n Most real problems are in the second layer.<\/strong> Companies configure access rights carefully and leave record rules wide open, so a salesperson who should see their own accounts can see everybody’s.<\/p>\n FIGURE 1: THE TWO LAYERS<\/p>\n Access rights<\/p>\n Record rules<\/p>\n Permissions are granted through groups<\/strong>, not to individuals.<\/p>\n A user belongs to groups \u2014 Sales \/ User, Sales \/ Manager, Accounting \/ Billing \u2014 and each group carries a set of rights on a set of models.<\/p>\n Four separate permissions per model: read, create, edit, delete<\/strong>. They are independent, and that matters. Somebody can often read records they cannot edit, or create records they cannot delete.<\/p>\n Delete is worth restricting specifically.<\/strong> 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.<\/p>\n This is where the useful control lives.<\/p>\n A record rule is a condition applied to a group. Members of that group only see records matching it.<\/p>\n Common patterns:<\/strong><\/p>\n Own records only.<\/strong> A salesperson sees opportunities where they are the salesperson.<\/p>\n Own team.<\/strong> A manager sees their whole team’s records.<\/p>\n One company.<\/strong> In a multi-company setup, users see only their company’s data.<\/p>\n One warehouse or branch.<\/strong> Staff see only their location.<\/p>\n Portal customers.<\/strong> Customers see only their own orders and invoices.<\/p>\n Two things to know:<\/strong><\/p>\n 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.<\/p>\n Administrator bypasses them. Anyone with administrator access sees everything, which is one reason to keep that group very small.<\/p>\n Do not assume. Log in as the user.<\/strong><\/p>\n Odoo lets an administrator impersonate a user in developer mode, or you can create a test account in the relevant group.<\/p>\n Then check:<\/p>\n That last one catches people out.<\/strong> 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.<\/p>\n FIGURE 2: FOUR CHECKS BEFORE YOU TRUST YOUR PERMISSIONS<\/p>\n Log in as a real user<\/p>\n Check both directions<\/p>\n Check reports<\/p>\n Check delete<\/p>\n Customers and suppliers with portal access are users too, with a heavily restricted set of rights.<\/p>\n Standard behaviour is that they see only their own records.<\/strong> Verify it rather than assuming \u2014 log in as a portal user and check.<\/p>\n And test it again after any custom development that touches portal-visible data.<\/strong> Custom code can accidentally bypass record rules, and portal data is the worst place for that to happen.<\/p>\n If you run more than one company in one database, this is where record rules do the heavy lifting.<\/p>\n Users are assigned to companies. Record rules keep each company’s data separate. Users with access to several can switch between them.<\/p>\n Get this right at setup.<\/strong> Untangling mixed company data afterwards is difficult and it affects your accounts, not just your screens.<\/p>\n And test it properly.<\/strong> Create a user in one company and confirm they cannot see the other’s customers, orders or figures.<\/p>\n Five, and they appear in almost every unreviewed installation.<\/p>\n Everyone is an administrator.<\/strong> Set during implementation when everyone needed access to test, never tightened. Administrator can delete records, change valuation methods and export everything.<\/p>\n Record rules never configured.<\/strong> Access rights carefully set, record rules left open, so everybody sees everything within the apps they can reach.<\/p>\n Rules never tested with a real login.<\/strong> Configured, assumed correct, wrong.<\/p>\n Leavers still active.<\/strong> Deactivation should be part of your leaving process. Most companies find at least one when they check.<\/p>\n Shared logins.<\/strong> They destroy every audit trail Odoo keeps. You can see what was done and not who did it.<\/p>\n FIGURE 3: TWO WAYS PERMISSIONS END UP<\/p>\n Well controlled<\/p>\n Drifted<\/p>\n Worth knowing if you commission development.<\/p>\n A custom module can define its own access rights and record rules, and it can also bypass them<\/strong> \u2014 deliberately or by accident.<\/p>\n Two questions to ask a development partner:<\/p>\n What access rights does this module define, and which groups get them?<\/strong><\/p>\n Does any of this code run with elevated privileges, and if so, why?<\/strong><\/p>\n There are legitimate reasons for elevated code. There should be a stated reason, and somebody should have reviewed it.<\/p>\n It takes an afternoon and it is the single most useful security habit.<\/p>\n Roles drift.<\/strong> 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.<\/p>\n Access rights<\/strong> decide which apps and models people can reach. Record rules<\/strong> decide which records they see within them.<\/p>\n Most problems are in the second layer, and most of those are because record rules were never configured or never tested.<\/p>\n Log in as a real user and check.<\/strong> Administrator bypasses the rules, so testing as administrator tells you nothing.<\/p>\n Keep administrator small, deactivate leavers, use individual logins, and review once a year.<\/p>\n Not sure who can see what in your Odoo?<\/p>\n Get in touch. We will test your record rules with real logins \u2014 which is the only way to find out what people can actually see.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9095,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9094","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\n\n
\n
Access rights<\/h2>\n
Record rules<\/h2>\n
Testing them<\/h2>\n
\n
\n
\n
\n
\n
Portal users<\/h2>\n
Multi-company<\/h2>\n
The mistakes that recur<\/h2>\n
\n
\n
Custom modules and security<\/h2>\n
A yearly review<\/h2>\n
\n
The short version<\/h2>\n