- Home
- Apps
- SaaS Tools
- Advanced Access Rights Control
Illustrative previewA build-to-order Odoo permissions layer that gives you truly granular,
role-based access control across models, records, fields, menus, and actions.
ECOSIRE scopes, builds, installs, and supports it against your exact org chart.
What is Advanced Access Rights Control?
A build-to-order Odoo permissions layer that gives you truly granular, role-based access control across models, records, fields, menus, and actions. ECOSIRE scopes, builds, installs, and supports it against your exact org chart. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Key Features
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your Odoo.
- 3
Go live + support
You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Technical Specifications
- Odoo Compatibility
- Odoo 17, Odoo 18, Odoo 19
- Editions
- Enterprise & Community
- License
- Licence confirmation required
- Python Requirement
- Python 3.10+
- Database
- PostgreSQL 12+
About this Product
Every growing Odoo deployment eventually hits the same wall: the native permission model is coarser than the business needs. Odoo controls access through ir.model.access.csv (create/read/write/unlink per group per model) plus ir.rule record rules, but out of the box you cannot cleanly say "this group may read the customer record but never see the credit limit field," or "salespeople may edit their own draft quotations yet only read confirmed ones," or "warehouse leads see stock moves for their own warehouse and nothing else." Teams end up cloning groups endlessly, hand-editing dozens of CSV lines, and layering domain-based record rules that are hard to audit and easy to break on the next upgrade. The result is either over-permissioned users (a compliance and data-leak risk) or a brittle web of custom groups nobody fully understands.
This is a build-to-order module that ECOSIRE designs and engineers to your actual roles. We model your access matrix as first-class configuration: a permission-profile layer sitting on top of res.groups, with per-model CRUD, field-level read/write masking, menu and action visibility, and dynamic record rules generated from your criteria (owner, sales team, company, warehouse, region, or document state). Field masking is enforced on the server, not merely hidden in the view — we combine view groups= attributes with fields_get filtering and read/write guards on models.Model, so a restricted field cannot be exfiltrated or written through the ORM, a custom XML-RPC/JSON-RPC client, or an exported action. Every profile change is captured in an audit log so you can prove who could see what, and when.
Technically, the module ships as a proper addon with its own __manifest__.py, declaring dependencies only on the apps you actually restrict. Permission profiles are stored models with @api.depends compute chains that materialise into concrete ir.model.access and ir.rule records, so the resulting security stays native and upgrade-safe rather than living in a runtime monkey-patch. Configuration is driven from clean OWL/XML backend views (an access matrix editor, per-field toggles, and a "simulate as role" preview), and where policy touches printed output we can gate QWeb report fields and add automated actions that flag or block privilege escalations. It is built and tested for Odoo 17.0, 18.0, and 19.0, and we account for Community vs Enterprise differences up front — some approval and audit-trail primitives exist only in Enterprise, so we confirm your edition during scoping and implement the equivalent cleanly where you are on Community.
Delivery is build-to-order, not an instant download. After a short scoping call we map your roles into an access matrix, agree the exact rules, and give you a fixed quote. We then build on a branch, deliver to a staging database for UAT, and only promote to production once you sign off — with a rollback plan in hand. Typical delivery is one working week from confirmed scope, depending on how many roles and edge-case rules you need. Pricing starts from $999 (indicative, single-company base scope); multi-company access separation, a larger number of role profiles, and deep field-level masking across many models increase the quoted scope.
What you get
- Installable, version-pinned source code for your build (Odoo 17.0, 18.0, or 19.0 as scoped)
- Installation and configuration on your environment, with your role matrix loaded and verified
- Technical documentation: model design, generated `ir.model.access`/`ir.rule` mapping, and field-guard logic
- End-user and administrator guide plus a live training session for your Odoo admins
- UAT on a staging database with a documented test matrix and a signed-off rollback plan
- Post-go-live support window for defect fixes and access-rule adjustments
- Handover of the private Git repository with full commit history
Who this is for
Compliance & Risk Officer
Needs to prove least-privilege access for audits — that finance figures, salaries, and customer PII are visible only to authorised roles, with a change log to evidence it. Wants field-level masking that survives the ORM and external API, not just hidden UI.
Odoo Administrator / ERP Lead
Manages a sprawl of custom groups and CSV edits and is tired of the maintenance and upgrade breakage. Wants one clean access matrix, a 'simulate as role' preview, and rules that materialise into native security instead of runtime hacks.
Operations / Department Manager
Runs a team that should only touch their own records — their warehouse, their region, their team's quotations. Needs record-level scoping (owner/team/company) without over-exposing the rest of the ERP.
Multi-Company Group CFO
Oversees several legal entities in one Odoo database and needs staff walled into their own company's data, with a few cross-company roles carefully permitted. Needs `company_id`-scoped profiles and separation that holds across reports and the API.
How Advanced Access Rights Control Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Field-level read/write masking | Server-enforced via fields_get filtering and read/write guards | Possible but you build and test the guards yourself | Often view-only hiding that leaks via the ORM/API | Not supported — access is per-model, not per-field |
| Record-level scoping | Dynamic ir.rule from owner/team/company/warehouse/state | Hand-written record rules to design and maintain | Fixed rule set, limited to the vendor's assumptions | ir.rule available but manual and hard to audit at scale |
| Fit to your org chart | Engineered to your exact roles during scoping | Fully bespoke, at full custom-build cost and risk | Generic — you bend your roles to fit the app | You clone groups and edit CSV by hand |
| API / XML-RPC parity | Hidden fields and blocked records cannot be pulled externally | Depends entirely on your implementation quality | Frequently bypassable through the external API | Enforces model access but not field-level masking |
| Auditability | Built-in change log of who granted what, and when | Only if you build audit logging yourself | Rarely included; varies by vendor | No native permission-change audit trail |
| Upgrade safety | Materialises into native security records, upgrade-friendly | Risk depends on how it was written | May break on version changes; fixes wait on the vendor | Native but manual re-work each major version |
| Support & ownership | Support window plus full Git repo handover to your team | You own it, including all future maintenance | Vendor support only; no source control of your rules | Self-supported; community forums only |
| Time to value | Build-to-order, typically one working week from confirmed scope | Longest — full spec, build, and test cycle | Instant install, but configuration and gaps eat the time | Immediate but capped at coarse per-model control |
Frequently Asked Questions about Advanced Access Rights Control
How long does delivery take?
This is a build-to-order module, so it is engineered for your roles rather than downloaded instantly. Typical delivery is one working week from confirmed scope. Simpler matrices (a handful of roles, one company) land toward the shorter end; deep field masking across many models and multi-company separation take longer. We agree the timeline in writing before we start.
How is pricing worked out?
Pricing starts from $999 as an indicative figure for a single-company base scope. After a short scoping call we map your role matrix and give you a fixed, written quote. Drivers that increase scope include multi-company separation, a large number of role profiles, and field-level masking across many models. You approve the fixed quote before any build begins — no open-ended billing.
What about support and future Odoo updates?
Every build includes a post-go-live support window for defect fixes and access-rule tweaks. Because the module materialises into native `ir.model.access` and `ir.rule` records rather than runtime patches, it is upgrade-friendly. When you move to a new Odoo version (for example 18.0 to 19.0) we can quote a compatibility pass, and you receive the Git repo so your own team can maintain it too.
Is this different from just editing groups and access rights myself?
Native groups and `ir.model.access.csv` give you per-model CRUD, and record rules give you row filtering, but neither gives clean field-level read/write masking that also holds over XML-RPC/JSON-RPC, nor a manageable UI for a large matrix, nor an audit trail. We build that layer on top of the native primitives so you get the granularity without the CSV sprawl and upgrade fragility.
Does it work on Odoo Community, or only Enterprise?
It works on both. Some approval and audit primitives ship only in Enterprise, so during scoping we confirm your edition and implement the equivalent cleanly where you are on Community. We build and regression-test against Odoo 17.0, 18.0, and 19.0.
Can restricted fields still leak through the API or a data export?
No — that is the point of enforcing on the server. We guard `read`/`write` at the `models.Model` layer and filter `fields_get`, so a masked field is not returned through the ORM, a custom XML-RPC/JSON-RPC client, or an export action. View-level hiding alone is not relied upon.
How do you deploy without breaking our live system?
We build on a branch and deliver to a staging database first. You run UAT against a documented test matrix, we hand you a rollback plan, and only after your sign-off do we promote to production. You keep the Git repo and full history throughout.
Related Modules

Activity 360: Activity Dashboard & Management
A build-to-order Odoo module that turns scattered mail.activity records into one prioritized command center, with shared participants, due-date tracking, and multi-model activity management. ECOSIRE scopes, builds, installs, and supports it for your instance.

ADMS Push Attendance (ZKTeco/eSSL/Anviz)
Real-time biometric punches pushed into Odoo via the ADMS/iClock protocol — no polling, works behind a firewall. ECOSIRE builds & installs it.

Advanced Cash on Delivery (COD) Suite for Odoo
Smart COD for Odoo eCommerce: cart limits, geo-rules, COD fees, OTP verification and prepaid nudges to slash fake orders and RTO losses.

Advanced DMS for Odoo
A build-to-order Odoo document management module with in-browser PDF annotation, full version history, and record-rule-driven access control. ECOSIRE scopes, builds, installs, and supports it — this is not an off-the-shelf download.
Advanced Access Rights Control
A build-to-order Odoo permissions layer that gives you truly granular, role-based access control across models, records, fields, menus, and actions. ECOSIRE scopes, builds, installs, and supports it against your exact org chart.
- Permission-profile layer on top of native `res.groups`, so roles stay Odoo-native and upgrade-safe
- Per-model CRUD control (create/read/write/unlink) materialised into real `ir.model.access` records
- Field-level read and write masking enforced server-side via `fields_get` filtering plus `read`/`write` guards on `models.Model`
- View-layer hiding through `groups=` attributes kept in sync with the server-side field guards (no view-only bypass)