Odoo access rights need a role matrix and a failed-action test
Define Odoo 19 roles by records and permitted actions. Use a role matrix and negative tests to check access without relying on an administrator demo.
Define Odoo access by the records a role needs and the actions it may perform. Then test both permitted work and prohibited work using an ordinary account for that role. A demonstration under an administrator account cannot establish that the role is configured correctly.
For Odoo 19.0 Enterprise, distinguish model access, record restrictions and business approval rules. They answer different questions: can this user operate on this kind of record, which records can they access, and may they authorize this particular business action?
Odoo's 19.0 security reference explains that access rights grant model operations and are additive across groups. Record rules are evaluated after access rights. Therefore, adding another group can expand access; a narrowly named group does not prove that the user's combined access is narrow.
Write the business rule before choosing groups
Start with a small matrix of actual responsibilities. The sample below describes a proposed policy. It is not Odoo's default behavior or a ready-to-install configuration.
| Role | Must be able to do | Must not be able to do | Record scope |
|---|---|---|---|
| Field technician | Read assigned scope and record work | Change approved commercial terms | Assigned jobs |
| Dispatcher | Schedule work and reassign a visit | Approve a supplier payment | Relevant service operation |
| Purchasing user | Prepare a purchase request | Approve their own exception beyond policy | Relevant purchasing records |
| Billing user | Prepare charges from approved work | Modify the field evidence to justify a charge | Jobs ready for billing |
| Operations manager | Review exceptions and assign an owner | Gain unrelated confidential access by accident | Agreed operating scope |
Replace vague labels such as “full access” with actions and limits. View, create, edit and delete are useful starting distinctions, but your process may also need submit, confirm, export or approve tests. Ask the implementer how the particular action is enforced in the selected applications.
An approval limit written in a procedure is not automatically a software restriction. Record whether enforcement comes from standard configuration, an approval feature, custom code or an operational review outside the system. Assign ownership to any remaining manual control.
Test the combined account, including its unwanted paths
Create a permitted test account with the intended role. Do not borrow another employee's password. In a non-production environment, give that account the same group combination and company scope intended for real work.
Test a normal record first. Then attempt the forbidden action on a separate fictional record. Try another record outside the permitted scope. Test the relevant report or export too, because preventing an edit is different from preventing a person from seeing information.
Record the account's role, the attempted action, the expected result, the observed result and the evidence. A denied action passes only if the legitimate work still succeeds. Blocking everyone is not a useful access design.
Odoo's access-rights guide warns that changing permissions can leave users without access needed to administer the database. Keep a verified administrator recovery route while testing; do not experiment by removing production administrators.
Watch what changes when a person changes jobs
A promotion, temporary assignment or second company can alter the group combination. Re-run the relevant tests after that change. Name someone responsible for removing access that is no longer needed, and retain the request and outcome in the access record.
For integrations and AI, test the identity the connection actually uses. A limited interface does not compensate for an overly broad service account. The AI permissions worksheet extends the same record-and-action reasoning to automated work.
Put this matrix into the ERP acceptance test pack. Make a forbidden action a real test case with an owner and expected denial. The useful completion evidence is a role that can finish its work while the defined prohibited actions fail.