Designing Odoo access rights and record rules

Odoo security design should start from tasks and sensitive data, then test model access, record scope, company context, and exceptional collaboration cases.

Hiding a menu is not security. Users may still reach records through links, reports, related fields, imports, or API calls. Odoo access must be enforced at the model and record level. Build roles from tasks List what each role creates, reads, updates, deletes, approves, exports, and configures. Separate daily operations from administration. Avoid giving broad manager groups simply to solve one missing permission. Distinguish model and record access Access control lists determine allowed operations on a model. Record rules limit which records within that model are available. Test both because a correct menu and ACL can still expose another salesperson's customers or another company's documents. Test collaboration exceptions Ownership changes, team pipelines, shared contacts, substitutes, leave cover, multi-company managers, and cross-department handover often break simplistic rules. Write these cases as explicit tests. Protect sensitive actions Review exports, chatter attachments, reports, automated actions, server configuration, and mass editing. A user may not need accounting screens but may still see financial fields through a related model. Practical checklist Describe permissions using real user tasks. Test model operations and record visibility separately. Include own, team, shared, archived, and multi-company cases. Review exports, reports, attachments, and related records. Retest with actual non-admin accounts after every change. Final decision The safest design gives people enough context to complete their work while keeping administrative and sensitive capabilities explicit. Testing as administrator proves almost nothing about user security.