Odoo 19 users can access records, menus, or documents they should not see after a migration—or lose access to records they previously could manage.
The cause can be deeper than a user’s assigned permissions. After an Odoo 18 to Odoo 19 migration, user roles, groups, access control lists (ACLs), record rules, multi-company restrictions, and application-specific security settings can affect the access a user actually receives.
The key diagnostic question is:
Which security layer is allowing or blocking the affected operation?
This guide explains how to trace Odoo 19 access-right problems after migration across roles, groups, ACLs, record rules, and company access—without fixing the symptom by giving users broader permissions than they need. For broader Odoo ERP implementation requirements, security configuration should be checked as part of the overall implementation and migration process.
Why Odoo 19 Access Rights Can Behave Differently After Migration
Odoo does not determine access from a single permission field. A user’s effective access can be influenced by roles, security groups, inherited groups, model access rights, record rules, multi-company configuration, application-specific permissions, document permissions, custom module security, and migrated configuration.
Odoo 19 uses roles to provide predefined access levels, while groups determine the detailed permissions associated with those roles. Users can also receive additional permissions through inherited groups.
This matters after migration because a user may appear to have the expected application-level permission while receiving additional access through another group.
Odoo 19 also introduced changes to the user role structure compared with earlier versions. The Odoo community has documented migration-related questions around the change from the previous Internal User concept to the User role and the introduction of the broader Administrator role.
Therefore, when access changes after an Odoo 18 → Odoo 19 migration, checking only the visible application permission is not enough.
How Odoo 19 Access Rights Actually Control Records
Two security layers are particularly important when investigating record-access problems:
Access Rights (ACLs) determine whether a user can perform operations on a model:
- Read
- Write
- Create
- Unlink
These permissions are additive across the user’s groups. If multiple groups grant different permissions, those permissions combine.
Record Rules determine which records the user can access within a model. They use domains to restrict record access after model-level access has been granted.
This creates an important distinction:
Model access → Allowed
Record access → Restricted
A user can therefore have permission to access a model but still be unable to access specific records. Conversely, an additional group can grant broader model access than intended.
Access Rights vs Record Rules
| Security layer | Controls |
| Role | Broad user access level |
| Group | Permission bundle and inherited permissions |
| Access Right / ACL | Read, write, create, and delete access to a model |
| Record Rule | Which records can be accessed |
| Multi-company rules | Which company-specific records can be accessed |
This is why removing one visible permission from a user may not resolve an access problem. The effective permission can come from another group or be restricted by a record rule.
Check the User Role and Groups First
When a migrated user has unexpected access, start with the user’s current security configuration.
Open the user and review the Access Rights configuration. In Odoo 19, the available roles include:
- Administrator
- User
- Portal
- Public
Then enable developer mode and inspect the user’s technical groups.
Check for:
- Selected groups
- Inherited groups
- Application-specific administrator groups
- Groups added by custom modules
- Groups carried over from the previous Odoo configuration
The diagnostic path is:
User → Role → Selected Groups → Inherited Groups → Access Rights
Odoo groups can imply other groups through implied_ids. When one group implies another, assigning the first group can provide the permissions associated with the implied group.
Therefore, do not judge a group’s effect from its name alone. Inspect the group’s:
- Access Rights
- Record Rules
- Menus
- Views
- Inherited groups
If an unexpected permission comes from an inherited group, removing an unrelated application permission will not address the underlying security configuration.
When the User Can Open a Record They Should Not Access
If a user can access a record they should not see even though the visible application permission appears restricted, investigate the model’s security configuration.
First identify the technical model involved, then check:
- Which groups the user belongs to.
- Which ACLs apply to those groups.
- Whether the affected operation is read, write, create, or delete.
- Which record rules apply to the model.
- Whether those rules apply to the user’s groups.
- Whether multi-company configuration affects the record.
- Whether a custom module adds additional security rules.
If the ACL allows the operation but the user can access records they should not see, inspect the applicable record rules and their domains.
When Odoo 19 Shows “Access Denied” After Migration
The opposite problem can also occur:
The user could perform the operation before migration but receives an access error after migration.
Do not immediately promote the user to Administrator.
Identify the failed operation:
Read → Write → Create → Delete
Then identify the affected model and compare the user’s current groups with the pre-migration security configuration.
If the model has the required ACL but access is still denied, inspect the applicable record rules. After model-level access is granted, record rules can further restrict which records the user can access.
If the problem affects only certain records, investigate the record rules before changing model-level permissions.
Multi-Company Access Can Change the Result
Multi-company configuration is another important layer when access behaves differently after migration.
A user may have:
Correct application permission + correct group + correct ACL
but still receive a different result because the active company, allowed companies, record company, or company-specific record rules differ.
When the problem affects records belonging to another company, compare:
- User’s allowed companies
- Current active company
- Record’s company
- Multi-company record rules
- Custom company-specific rules
Do not remove a company restriction simply to make a record visible. Identify why the record is outside the user’s intended company access first.
Odoo 19 Documents Access Rights After Migration
Documents requires an additional check because access can also be configured at the folder and file level.
If the migration problem involves Documents, check:
- Documents application permissions
- Folder ownership and sharing
- File ownership and access
- Viewer and editor permissions
- Direct sharing permissions
Odoo also centralizes documents from other applications into Documents folders, so application-generated files can introduce another configuration layer.
Therefore, a Documents access problem should not automatically be treated as a general Documents application permission problem.
Why Migration Can Expose Existing Security Problems
Migration does not necessarily create every security problem from scratch.
It can expose differences between the previous security configuration and the Odoo 19 security structure, particularly when the database contains:
- Custom modules
- Custom groups
- Custom record rules
- Modified access-control files
- Custom user roles
- Multi-company rules
- Application-specific security changes
The important question is not simply:
“Which permission changed?”
It is:
“Which security definition now produces a different effective permission?”
That requires comparing the affected model, user groups, ACLs, record rules, company configuration, and custom security definitions.
How to Diagnose Odoo 19 Access Rights After Migration
Use this sequence before changing permissions.
Identify the exact failure
Record the:
- User
- Model
- Record
- Operation
- Company
- Error message
- Access path
Identify whether the problem is unexpected access or access denied, and whether it occurs during read, write, create, or delete.
Compare the affected user’s security configuration
Compare the affected user with a working user or the pre-migration configuration.
Check:
- Role
- Selected groups
- Inherited groups
- Application permissions
- Allowed companies
- Default company
Check ACLs and record rules
Identify the affected model and inspect the applicable ACLs for:
Read / Write / Create / Unlink
Because ACL permissions are additive across groups, check all groups that apply to the user.
If the ACL is correct but specific records remain inaccessible, inspect the applicable record rules, including:
- Rule domain
- User groups
- Operation
- Global vs group-specific rules
- Company conditions
Check migration-specific security changes
Compare the Odoo 18 and Odoo 19 security configuration where possible.
Focus on:
- Role changes
- Group changes
- Custom modules
- ACL definitions
- Record-rule definitions
- User assignments
- Multi-company configuration
Test with the affected security level
Do not use Administrator access as the final test because it can hide permission problems.
Test using the affected user’s actual role or a controlled test user with equivalent permissions.
Verify the exact record and exact operation again.
Investigate custom security code
If the user, groups, ACLs, record rules, and company configuration appear correct but the behavior remains inconsistent, investigate custom modules and security definitions.
Custom code can change how operations are performed and may affect the normal security evaluation.
At this stage, repeatedly changing user permissions is more likely to hide the problem than solve it.
Do Not Fix Access Problems by Making Users Administrators
Giving an affected user Administrator access can appear to solve an access-denied problem because it grants substantially broader permissions.
It is not a proper security fix.
Instead, trace the actual permission path:
Identify the model → identify the operation → identify the group → check ACL → check record rule → check company → check customization.
This preserves the intended security boundary instead of removing it.
When Odoo 19 Access Rights Need Technical Investigation
A deeper technical review is justified when:
- Permissions changed immediately after migration.
- Access differs depending on the record or company.
- Standard ACLs appear correct but access is still denied.
- Record rules produce unexpected results.
- Custom modules contain security groups, ACLs, or record rules.
- Odoo 18 and Odoo 19 security structures behave differently.
At this point, the investigation should move from individual user settings to the database’s security architecture:
Roles → Groups → ACLs → Record Rules → Companies → Custom Modules → Business Records
This is the level at which persistent post-migration access problems need to be resolved.
When Odoo 19 Access Rights Are an ERP Configuration Problem
A permission issue affecting one user may be limited to that user’s configuration. When the same problem affects multiple users, applications, companies, or migrated records, the underlying ERP security configuration should be reviewed.
This can involve connected user roles, security groups, ACLs, record rules, multi-company configuration, Documents permissions, custom modules, and migration changes.
For broader security, migration, and configuration requirements, Odoo ERP Implementation Company can help review the underlying ERP configuration rather than repeatedly modifying individual users.
Odoo 19 Access Rights Troubleshooting Checklist
Before changing a user’s role or adding permissions, verify:
- Affected user: Which user has the problem?
- Operation: Read, write, create, or delete?
- Model: Which Odoo model is affected?
- Records: Does the issue affect all records or only specific records?
- Role & groups: What role and security groups does the user have?
- Inherited groups: Are additional permissions received through group inheritance?
- ACLs: Does an applicable group provide the required model permission?
- Record rules: Which rules and domains apply to the operation?
- Company: Is the record within the user’s allowed companies and current company context?
- Documents: Are folder, file, or sharing permissions involved?
- Migration: Did the behavior begin after the Odoo upgrade?
- Customization: Do custom modules modify groups, ACLs, record rules, or other security definitions?
- Testing: Does the issue reproduce with a controlled non-administrator user?
Use this sequence to identify the security layer causing the problem before changing permissions. It is more reliable than repeatedly adding access until the error disappears.
Frequently Asked Questions
Access behavior can change after migration because of differences in user roles, security groups, inherited permissions, record rules, multi-company configuration, and custom security settings between the previous and Odoo 19 environments.
Access can come through another group, inherited group, ACL, record rule configuration, company access, or application-specific permission. ACLs determine model-level operations, while record rules further restrict which records can be accessed.
Identify the affected user, model, record, and operation first. Then check the user’s groups, ACLs, record rules, company access, and custom security configuration. Test the result with the affected security level rather than granting Administrator access as a workaround.
Conclusion
Odoo 19 access-right problems after migration should be traced to the security layer causing the issue, rather than fixed by adding broader permissions.
The goal is not simply to restore access, but to restore the correct access without weakening the security model.
