Odoo module
Access Control
Hiding is not locking: permissions are enforced on the server.
Define who can see and do what in Odoo. You set it up from the screen itself, without writing code. Whole-model fields, operations and records are enforced on the server, so an import or an external call cannot bypass them.
Price€180One-time payment · taxes not included
Compatible with Odoo 16, 17, 18 and 19: a single purchase covers all four versions.
Schematic illustration. Not a screenshot of the product.
- 9
- areas you can restrict by role
- 6
- model operations you can block
- 3
- scopes to limit the visible records
- 0
- activation keys or external services
The problem
In Odoo, most permissions are defined in code
To hide a field, block a button or restrict a menu for a role, you normally have to edit XML, add a group to a view or write a record rule by hand. The person who knows what each profile should see, the administrator, cannot apply it from where the need appears: the screen in front of them.
It requires changing code
Inherited views, groups in the XML and rules written as domains. Every permission change becomes a small development task.
Hiding on screen does not protect the data
If a restriction only affects the view, the field can still be written through an import or an external call. It looks protected, but it is not.
It is hard to know what each role sees
Verifying a restriction usually means creating a test user, switching sessions and repeating the process every time a rule changes.
Access Control solves both problems: you configure it from the screen and it is enforced for real, in the Odoo ORM.
What you can restrict
Nine areas of control, configured from the screen itself
A single gesture covers the interface and the model behind it. Each card states where the restriction is applied: on screen, on the server, or both.
Fields
Hide a field, make it read-only or make it required for a role, in a specific view or across the whole model.
Example: The sales team cannot see customers’ bank accounts.
Server, when it covers the whole model
Buttons
Hide any object or action button on a form or a list. This hides the button; to prevent the operation itself, combine it with a model capability.
Example: A role does not see the Cancel button on sales orders.
Screen
Menus
Hide a single submenu or a whole top-level menu, with all its entries.
Example: The sales team does not see the Reporting menu.
Screen
Model capabilities
Block create, edit, delete, duplicate, archive or export on a model. The button disappears and the server refuses the operation.
Example: Warehouse cannot delete delivery orders.
Screen and server
Actions and reports
Remove from the Action and Print menus the reports and server actions a role should not use.
Example: Only Management can print the margins report.
Screen
View types
Remove the List, Kanban, Pivot, Calendar, Graph, Activity and other view switchers a role should not use.
Example: Sales works in Kanban and has no access to the Pivot view with the totals.
Screen
Notebook tabs
Hide an entire tab of a form, not just the fields it contains.
Example: Sales does not see the accounting information tab.
Screen
Search filters
Hide specific filters and group-bys from the search menu.
Example: Nobody can group by salesperson to compare results.
Screen
Records (row level)
Limit the rows a role can see: only its own, only those of its company, or those matching a domain you define.
Example: Each salesperson sees only their own orders.
Server (native Odoo rule)
Real enforcement on the server
Hiding is not the same as locking
Server-side restrictions are checked in the Odoo ORM, so they reach the interface, imports, external calls and any other module that writes data. Here is exactly what is enforced on the server and what applies only on screen.
- The interfaceHidden
- The server (ORM)Blocked
- Imports and APIBlocked
Server-side blocking: whole-model fields, model capabilities and records.
That is why every card states its layer. If data must be truly protected, use whole-model fields, model capabilities or record restrictions.
The server refuses
- Creating or writing a field that is hidden or read-only for the role: access error.
- Leaving empty a field that is required for the role, on create or edit: validation error.
- Creating, editing, deleting, duplicating, archiving, unarchiving or exporting when that capability is restricted.
- Accessing rows outside the role’s scope, through native Odoo record rules.
The server blanks
- A hidden field returns an empty value in RPC reads (for example read and search_read); it does not merely disappear from the form.
- Computed fields that depend on a hidden field keep working, because internal access is left untouched.
On screen only
- Rules scoped to a specific view: on the server, only whole-model rules apply.
- Buttons, menus, tabs, filters, view types, actions and reports: they are removed from the interface.
- Internal processes that Odoo runs as superuser are not restricted: that is the administration path.
How it works
Three steps, no configuration screens
You turn on access mode, select the element you want to restrict and choose the role. That is the whole workflow.
- 01
Turn on access mode
Click the lock in the top bar. The screen becomes interactive: every field, button, menu and tab becomes a selectable element. Only the people who manage permissions see the lock.
- 02
Select the element to restrict
Point at the real element: a field, the New button, a menu entry, a tab, a filter. A panel opens right there. On a top-level menu, a first click opens the dropdown and a second click restricts it entirely.
- 03
Pick the role and the rule
Choose the role and whether to hide, make read-only or make required, for this view or for the whole model. You can also restrict all users except one role.
Who can define rules
Only the Access Control Manager group. System administrators receive it automatically; no other user can create, change or delete rules.
Preview as role
See Odoo exactly as another role sees it
Choose a role and the whole interface is redrawn as that role would see it: without the hidden fields, the blocked buttons or the restricted menus. Your own groups are not modified.
- You verify a rule instantly, without creating a test user or switching sessions.
- Your account keeps all its access: nothing is changed on your user.
- Only Access Control managers can use it. If another user tries to enable it through an external call, the attempt is ignored and their real restrictions keep applying.
Every rule, one click away
The rules for this screen, already filtered
From any record you open the list of rules that affect that model and that view. You see what is restricted and for whom, and you can switch a rule off with a toggle, without searching through a settings list.
- Filters by type: fields, buttons, menus, capabilities, actions, view types, tabs, filters and records.
- Filters by scope (whole model or one view) and grouping by type, model, role or restriction.
- A dedicated Access Control menu with the complete list of rules.
Sales orders list with three scopes to choose from: only their own records, only their company or a custom domain. Rows outside the scope are no longer visible to the role.
Sales orders
User: Lucía · Role: Sales
Records the role can see
Outside its scope
Visible orders: 3 / 6
Row-level security
Decide which rows a role can see at all
It is not only about how a field looks, but about which records exist for a role. You choose a scope and the module generates a native Odoo record rule for you.
Only their own records
Uses the model’s user field (user_id) and, when there is none, the user who created the record.
Only their company
Compares company_id with the user’s companies. Only available on models that have that field.
A custom domain
Any Odoo domain you define; for example, only contacts of type contact.
Native rules, combined safely
The generated rule is global and conditioned on the role, and it is combined with AND with the others. A permissive rule from another group therefore cannot undo it. It applies to read, write, create and delete, and it disappears when you delete the rule.
Comparison
What changes compared with configuring it by hand
The comparison is with what Odoo includes out of the box, not with specific third-party modules.
| Requirement | Odoo as shipped | Access Control |
|---|---|---|
| Hide a field from a role | Yes, by editing the view with groups (requires code). | Yes, from the screen. |
| Read-only or required per role | With code in the view. | Yes, from the screen. |
| Prevent a field from being written by import or API | Only if you program it in the model. | Yes: the server refuses it (whole-model rule). |
| Create, edit, delete, duplicate, archive or export per role | Model access rights, in the technical settings. | A panel on the screen itself, with server-side blocking. |
| Rows visible per role | Record rules, with the domain written by hand. | Own, Company or Domain selector; it generates the native rule. |
| See the interface as another role | Usually with a test user. | Preview as role, without switching sessions. |
Restricting only the view is not enough
A restriction that only affects the view leaves the data writable through an import or an external call. That is the difference between a tidy screen and an effective permission.
Safe by default
Native Odoo mechanisms, no external services
No rules, nothing changes
With the module installed and no rules, everything stays visible and editable. Each rule only removes access from a role.
The most restrictive rule prevails
When several rules affect the same field for a user, hide prevails over read-only, and read-only over required. Access is never opened up by a single stray rule.
No key, no external service
It requires no activation key and no external service. Your data and access rights never leave your Odoo.
Clean uninstall
Uninstalling the module removes the record rules it generated, so no orphaned restrictions are left behind.
One role, or everyone but one
Each rule can apply to the members of a role or to everyone who is not, whichever is simpler to express.
Designed not to slow Odoo down
Checks are skipped entirely when there are no rules of that kind and, when there are, they are looked up in a per-model, per-user cache that is invalidated whenever a rule changes. We do not publish benchmarks.
Who it is for
For whoever is accountable for permissions
Odoo administrators
They change permissions when the business requires it, from the screen and without waiting for development work.
Integrators and consultants
They deliver an implementation with closed, reviewable permissions and show the client how to adjust them on their own.
Companies under audit
They need to separate duties and be able to show which restrictions exist, for whom and where they apply.
Typical use cases
- Sales cannot see margins or costs.
- Warehouse cannot delete or duplicate delivery orders.
- Each salesperson sees only their own orders and customers.
- Nobody outside Management can export contacts.
- A read-only role sees the data but cannot create or edit it.
- Each company in the group sees only its own records.
What the purchase includes
Terms of purchase
What you receive, for how long and under what conditions.
- Module
- The complete Access Control module: the nine restriction areas, preview as role and the rules list.
- Odoo versions
- Odoo 16, 17, 18 and 19. The purchase gives access to all of them: if your company migrates to another version, it does not pay again.
- Editions and hosting
- Developed and tested on Odoo Community. It depends only on the base web module, so it installs the same way on Enterprise, on Odoo.sh and on self-hosted installations. It cannot be installed on Odoo Online (standard SaaS), because Odoo does not allow third-party modules there.
- License
- OPL-1 (Odoo Proprietary License v1.0): the code is readable and you may adapt it for your own use, but not redistribute it.
- License scope
- One license per company. It covers its production database and all of its test, staging and development databases, with no user limit. An integrator needs one license for each end client.
- Updates
- Bug fixes with no time limit for the versions you bought. Improvements, new features and adaptation to new Odoo versions are included for 12 months from the date of purchase.
- Support
- By email, in Spanish and English, for 12 months from the date of purchase. First reply within 2 business days at most. It includes help with installation and initial setup. It does not include custom work: see our custom development service.
- Refund policy
- 30 days, no conditions: if the module is not a fit, the full amount is refunded. If a conflict with another module appears within those 30 days, we fix it or refund your money.
- How it is delivered
- After your request, you receive the invoice and payment instructions by email. Once the payment is confirmed, you receive the download link for the module (all four versions) and the installation guide within one business day at most.
- How it is paid
- €180, one-time payment, with no subscription or instalments. Taxes not included: they apply according to your country and tax regime and are itemised on the invoice.
- Signing brand
- uKodeIT signs and sells the module.
Frequently asked questions
Common questions before installing it
What happens if I install the module and create no rules?
Nothing. Everything stays visible and editable for all users. Each rule removes access from one specific role.
Can a restriction be bypassed with an import or an external call?
For whole-model fields, model capabilities and records, no: the server refuses it. For buttons, menus, tabs, filters, view types, actions and reports, and for single-view rules, the restriction applies to the interface only.
Does it affect internal processes and scheduled jobs?
Processes that Odoo runs as superuser are not restricted, because they are the administration path and the way Odoo’s own internal processes run.
Who can create and change rules?
Only the Access Control Manager group, which system administrators receive automatically. Preview as role is limited to that same group.
Does it work on Community, Enterprise, Odoo.sh and Odoo Online?
Yes on the first three: it is developed and tested on Odoo Community and depends only on the base web module, so it installs the same way on Enterprise, on Odoo.sh and on self-hosted installations. It cannot be installed on Odoo Online (standard SaaS), because Odoo does not allow third-party modules there.
How does it affect performance?
When there are no rules of a given kind, the checks of that kind are skipped. When there are, they are looked up in a per-model, per-user cache that is invalidated whenever a rule changes. There are no published measurements.
Does it work with several companies?
The Only their company scope compares company_id with the user’s companies and is only offered on models that have that field. The module’s rules belong to the role, not to a specific company.
Can it conflict with other modules?
The module hooks generically into Odoo’s writing, reading, views, menus and actions, and we cannot guarantee compatibility with every third-party module. Our commitment is this: if a conflict appears in the first 30 days, we fix it or refund your money. Even so, it is worth trying it first on a copy of your database.
What happens when I uninstall it?
The record rules the module generated are removed, so no orphaned restrictions remain on your data.
Does it need an activation key or a connection to an external service?
No. Your data and access rights do not leave your Odoo.
Purchase
Access Control for Odoo
€180
Taxes not included: they apply according to your country and tax regime and are itemised on the invoice.
One-time payment. One license per company, covering its production and test databases. Full refund within 30 days.
Leave your details and you will receive the invoice and payment instructions by email. Once the payment is confirmed, we send you the download link (all four versions) and the installation guide within one business day at most.
uKodeIT is an independent Odoo integrator and is not an Odoo S.A. partner. Odoo is a trademark of Odoo S.A.
Permissions enforced on the server
Set up restrictions from the screen, verify them with preview as role, and let the server enforce the model-level and record-level ones.
€180