Generate Odoo Security Rules and Access Control

Odoo Security Rules helps write correct ir.model.access.csv entries (model-level access - who can read/write which models) and ir.rule domain-based record rules (record-level access - which records a user can see), the two layers Odoo uses to manage security.

Use this when setting up access rights for a new custom module, restricting records so users only see their own or their company's data, debugging "Access Denied" or "You are not allowed to access" errors, or implementing multi-company record visibility. It explicitly does not cover field-level access control (ir.model.fields read/write restrictions, which need custom OWL or Python overrides), full portal or public-user nuances (test those separately with base.group_portal), or PostgreSQL row-level security, since Odoo manages all security at the ORM layer - and any code running via sudo() bypasses ir.rule entirely, so record rules can't be relied on inside superuser-context code.

The workflow has three steps: activate by mentioning @odoo-security-rules and describing the access scenario; generate the correct CSV access lines and XML record rules for that scenario; or debug by pasting an access error and getting a diagnosis with the fix. A model-level access example:

id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_hospital_patient_user,hospital.patient.user,model_hospital_patient,base.group_user,1,0,0,0
access_hospital_patient_manager,hospital.patient.manager,model_hospital_patient,base.group_erp_manager,1,1,1,1

A record-level rule restricting users to their own records uses a domain_force like [('create_uid', '=', user.id)] scoped to a specific groups field; omitting that groups field makes the rule global and applies to all users, including admins. A multi-company variant instead checks ('company_id', 'in', company_ids) combined with an "or no company set" branch, using the plural company_ids so it covers every company a user belongs to.

Works against Odoo's res.groups, ir.model.access, and ir.rule models. It recommends base.group_erp_manager for ERP-manager-level access and a purpose-built custom res.groups record per module for manager roles, reserving base.group_system strictly for Odoo's technical superusers since it grants full server-configuration access.

Odoo developers configuring access rights for a new module, restricting record visibility by owner or company, or debugging a permission error, who need to get the CSV/XML syntax and group choice right the first time rather than accidentally granting a global or public-access rule. Best-practice guidance includes starting from the most restrictive access and opening it up as needed, testing rules as a non-admin user in debug mode since sudo() bypasses record rules entirely, and never granting perm_unlink = 1 to regular users unless deletion is an explicit business requirement.