Fix Odoo AccessError: You Are Not Allowed to Access Records
AccessError: You are not allowed to access records. This operation is allowed for the following groups
Also searched as
- Odoo You are not allowed to access this document error
- Odoo AccessError record rules fix
- Odoo ir.model.access.csv permission denied
- Odoo security restrictions contact your administrator
Short answer
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
Applies to: Odoo 14 through 18, Community and Enterprise
Diagnose and fix an Odoo AccessError
- 1Read the full error dialog - on a model-level error it names the model (e.g. sale.order) and lists the groups that already have access.
- 2Enable developer mode: Settings > General Settings > Activate the developer mode, or append ?debug=1 to the URL.
- 3Open Settings > Users & Companies > Users for the affected account and check the Access Rights tab for the relevant app, for example Sales: User vs Sales: Administrator.
- 4If the error names a specific group, add the user to that group (or a broader group that implies it) and retest.
- 5If no listed group fits, go to Settings > Technical > Security > Access Rights, filter by Model, and add or edit the row for that model and group with the needed Read/Write/Create/Unlink flags.
- 6If access rights look correct but the error persists, check Settings > Technical > Security > Record Rules for the same model - a domain filter, often on company_id, may be excluding the specific record.
- 7For a custom module, add or correct a line in security/ir.model.access.csv, then upgrade the module with -u module_name (or Apps > Update Apps List, then Upgrade).
- 8Retest as the affected user, not as Administrator - the Administrator (superuser) account bypasses most record rule checks, which hides the bug.
Model access rights vs record rules - two different layers
Odoo enforces security in two separate layers, and the error text tells you which one triggered. A model-level AccessError (missing ir.model.access.csv entry) reads roughly: You are not allowed to access X (model.name) records, followed by a list of groups that are allowed. This means the user's role has no ACL row for that model at all.
A record-level failure from ir.rule instead reads something closer to: The requested operation cannot be completed due to security restrictions - please contact your system administrator. This fires when the user does have model access, but the specific record fails a domain filter, most often a multi-company rule (company_id in allowed_company_ids) or a custom rule restricting rows to their own records.
Reading the error to find the missing group
The model-level message lists the exact groups already granted access, for example Sales / Administrator or Sales / User: All Documents. Compare that list against the affected user's Access Rights tab. If the user's current selection sits below the listed groups in the same category (for example Sales: User: Own Documents Only when the operation needs User: All Documents), raising that single dropdown often resolves it without touching the CSV at all.
Fixing it in a custom module
When the model belongs to a custom module rather than Odoo core, the missing ACL almost always lives in that module's security/ir.model.access.csv. Each row needs a unique id, the model reference in the form model_<technical_name>, the group_id (or blank for all users), and the four permission flags.
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_my_model_user,my.model.user,model_my_model,base.group_user,1,1,1,0
Multi-company record rules
In a multi-company Odoo install, the default record rule on most models restricts visibility to company_id in user.company_ids. A record created in Company B is invisible, and any write attempt raises AccessError, for a user whose Allowed Companies (Settings > Users, Multi Company section) does not include Company B - even if their group access rights are otherwise correct. Adding the company to the user's Allowed Companies list is the fix, not touching the ACL.
Common pitfalls
- !Testing as Administrator hides the bug entirely, since the superuser account bypasses most ir.rule checks.
- !Editing ir.model.access.csv but forgetting to upgrade the module - Odoo only re-reads security CSVs on install/upgrade, not on a plain server restart.
- !Confusing a model-level error (add a group) with a record-rule error (fix a domain or Allowed Companies) and editing the wrong layer.
- !Granting perm_unlink or perm_write broadly to fix one error, which then over-exposes the model to an entire group.
- !Forgetting that a Portal or Public user has its own, much narrower default access rights, separate from internal user groups.
How an ERP-grounded AI assistant handles this
Working out whether a specific AccessError comes from a missing ir.model.access.csv row or a company/record rule domain means reading two different security layers side by side with the user's actual group membership - tedious but mechanical. An ERP assistant like Netray's ERPray, grounded in the running Odoo instance's security configuration, can trace a reported AccessError back to the exact missing ACL row or the record rule domain that excluded the record, and state which group or Allowed Company setting fixes it, instead of a developer manually cross-referencing the Security menu.
Frequently asked questions
Why does the error only happen for one user and not for me as Administrator?
The Administrator (superuser) account bypasses most record rule (ir.rule) checks by design, so testing only as Administrator will never reproduce a record-rule AccessError. Always reproduce the issue logged in as the affected user or by impersonating them in debug mode.
I added the group but the AccessError still appears - why?
Group changes on an existing session sometimes need a logout/login to refresh cached access rights, and if the fix was in ir.model.access.csv rather than a group assignment, the module needs an actual upgrade (-u module_name) since Odoo only re-parses security CSVs during install or upgrade.
Does a record rule apply to Administrator too?
By default no - Odoo's ORM bypasses record rules for the superuser unless a rule is explicitly marked as applying to all users including the superuser (a checkbox on the rule). Most custom multi-company or ownership rules do not set that flag.
How do I find which record rule is blocking access?
In developer mode, go to Settings > Technical > Security > Record Rules, filter by the model name, and read each rule's Domain field. The rule whose domain the affected record fails (commonly a company_id or create_uid check) is the one to adjust or exempt.
Related
How to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
How-toHow to Run Requirements Planning (MRP) in SYSPRO
SYSPRO's MRP engine lives under Planning and Scheduling > Requirements Planning. Set planning parameters per warehouse, run the Requirements Calculation to net demand against supply, then review and release the resulting suggestions as purchase requisitions or work orders. A full regenerative run typically runs on a schedule, with net change runs in between to pick up new activity.
Error fixFix Fishbowl Error: MySQL Server Has Gone Away
This error means the Fishbowl Server lost its connection to the underlying MySQL database, usually because a session sat idle past MySQL's wait_timeout, MySQL itself restarted, or a large import or report exceeded max_allowed_packet. Raise the relevant MySQL timeout and packet settings, confirm the MySQL service is actually running, and restart both MySQL and the Fishbowl Server service.
Error fixQAD Says "Unable to Connect to the Application Server": How to Fix It
This error almost always means the Progress OpenEdge AppServer broker behind QAD is stopped, unreachable over the network, or out of licensed connections, not a database problem. Confirm the broker process is running and healthy in OpenEdge Explorer, check the port and firewall path from the client, then restart the broker with clean agent settings.
How-toHow to Close a Job in JobBOSS2
A job in JobBOSS2 will not close cleanly until every routing operation is marked complete, all material has been issued or returned, and all labor and cost transactions are posted. Review the job's Work In Process detail first, clear any open items, then change the job status to Complete and run final job costing before it is locked.
AI for ERPNatural Language Query for ERP Data: Ask SAP, Infor, or Oracle a Question in Plain English
See how natural language query over SAP, Infor, Oracle, and NetSuite data works: grounded text-to-SQL, role-based permissions, and a visible audit trail.
AI for ERPAI Agents for ERP, Running On-Prem
A practical guide to on-prem AI agents for ERP: what they can safely automate, where human approval belongs, and how to design the guardrails.
Stuck on Odoo (Community & Enterprise)?
Talk to engineers who work inside Odoo (Community & Enterprise) every week, and who build private AI that answers these questions from your own ERP data.