Odoo 20 Access Rights: Migrating to ir.access

For developers, the biggest Odoo 20 change isn't AI. It's security. Record rules are removed, and access rights now carry an optional domain. Model-level permissions and row-level restrictions live together in one model, ir.access.

It's a cleaner design. It also means every custom module with a security folder needs work before it'll install on 20.

What changed

Up to Odoo 19, security had two layers:

• ir.model.access: which groups can read, write, create or delete a model
• ir.rule: which records within that model they can see, using a domain

In Odoo 20, these are merged into ir.access. One entry says who can do what on which model, and optionally on which records.

The new CSV, in outline

Developer write-ups (Cybrosys has a detailed one) describe the shape of security/ir.access.csv like this:

• The four perm_* columns become a single operation column using letters, such as r for read or crud for full access
• domain_force from ir.rule becomes an optional domain on the same row
• The model is referenced by its technical name, for example project.task, instead of an XML ID
• The group is still referenced by XML ID

Check the exact column names and semantics against the official 20.0 developer documentation before you convert at scale. Details matter in security code.

How we'd migrate a module

1. Inventory every security file. ir.model.access.csv, every XML file with ir.rule records, and any code that creates rules dynamically.
2. Map each old line to a new one. Access lines become ir.access rows. Rules become domains on the matching row, or extra rows for groups that need different domains.
3. Watch the combination logic. Under the old model, global rules and group rules combined in specific ways. Don't assume the new model combines them identically. Write tests that prove who can and can't see what.
4. Remove the old files and the manifest references to them.
5. Install on a clean 20.0 database to catch loading errors early.
6. Test with real users, not the administrator. Admin bypasses most of what you're trying to test.

Tests worth writing

For each model your module secures:

• A user in the group can read and write the records they should
• A user in the group can't see records outside their domain
• A user outside the group gets an access error
• Multi-company users only see records for their allowed companies

These tests pay for themselves the first time someone changes a group.

Related Odoo 20 developer changes

• Tracking values are no longer stored. Tracking messages are generated on the fly, and a separate module exists if you need stored values.
• Font Awesome is replaced by Material Symbols, so custom views and widgets with fa- icons need updating.
• Push notifications move from Firebase to Odoo's own tooling.
• The external RPC db service is removed. XML-RPC and JSON-RPC are deprecated, with removal of the remaining services planned for Odoo 22. New integrations should use the JSON-2 API.

The full list is in the Odoo 20 upgrade checklist.

Our view

This is a good change. Two security layers that interacted in non-obvious ways caused plenty of real bugs. One model with explicit domains is easier to reason about. It just needs a careful, tested migration.

If you have many custom modules to port, our Odoo development and Odoo migration teams do this work. See also Odoo custom module development for the practices that make ports like this easier.