Skip to main content
Advanced Access Rights Control — A build-to-order Odoo permissions layer that gives you truly granular, role-based access con — 1/1Illustrative preview

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.

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

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)
Dynamic `ir.rule` record rules generated from criteria: record owner, sales team, company, warehouse, region, or document state
Menu, action, and button visibility control per profile so restricted users never see routes they cannot use
XML-RPC / JSON-RPC parity — hidden fields and blocked records cannot be pulled through the external API or exported actions
'Simulate as role' preview that renders any screen exactly as a chosen profile would see it, before you assign a single user
Audit log of every profile and permission change (who granted what, when) for compliance evidence
Optional automated actions that flag or block privilege-escalation attempts (e.g. a user editing their own access)
Multi-company aware: profiles can scope records and fields per `company_id` for group deployments
QWeb report field gating so sensitive values are suppressed on printed and PDF output for restricted roles
Bulk role assignment and profile cloning to onboard whole departments without hand-editing CSV
Built and regression-tested against Odoo 17.0, 18.0, and 19.0, with Community/Enterprise edition handling confirmed during scoping

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

  1. 1

    You order

    Start with a one-time build price. We scope it with you at kickoff.

  2. 2

    We build & install

    ECOSIRE builds, configures and installs it on your Odoo.

  3. 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

CriterionECOSIRECustom BuildCompetitorOdoo Native
Field-level read/write maskingServer-enforced via fields_get filtering and read/write guardsPossible but you build and test the guards yourselfOften view-only hiding that leaks via the ORM/APINot supported — access is per-model, not per-field
Record-level scopingDynamic ir.rule from owner/team/company/warehouse/stateHand-written record rules to design and maintainFixed rule set, limited to the vendor's assumptionsir.rule available but manual and hard to audit at scale
Fit to your org chartEngineered to your exact roles during scopingFully bespoke, at full custom-build cost and riskGeneric — you bend your roles to fit the appYou clone groups and edit CSV by hand
API / XML-RPC parityHidden fields and blocked records cannot be pulled externallyDepends entirely on your implementation qualityFrequently bypassable through the external APIEnforces model access but not field-level masking
AuditabilityBuilt-in change log of who granted what, and whenOnly if you build audit logging yourselfRarely included; varies by vendorNo native permission-change audit trail
Upgrade safetyMaterialises into native security records, upgrade-friendlyRisk depends on how it was writtenMay break on version changes; fixes wait on the vendorNative but manual re-work each major version
Support & ownershipSupport window plus full Git repo handover to your teamYou own it, including all future maintenanceVendor support only; no source control of your rulesSelf-supported; community forums only
Time to valueBuild-to-order, typically one working week from confirmed scopeLongest — full spec, build, and test cycleInstant install, but configuration and gaps eat the timeImmediate 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.

Request a quote

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)

Request a Quotation

Tell us about your Advanced Access Rights Control requirements and we'll send pricing, licensing options and a tailored proposal — usually within one business day.

No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.