跳至主要内容
产品详细信息以英文显示。翻译即将推出。
Advanced Access Rights Control — A build-to-order Odoo permissions layer that gives you truly granular, role-based access con — 1/1示意预览

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.

什么是 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.

核心功能

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

按需定制,全程代劳

无需自行搭建——由 ECOSIRE 构建、安装并提供支持的可用应用。

  1. 1

    您下单

    以一次性构建价格开始。我们在启动时与您共同确定范围。

  2. 2

    我们构建与安装

    ECOSIRE 在您的 Odoo 上构建、配置并安装。

  3. 3

    上线 + 支持

    约一个工作周内上线,并包含两周上线支持。我们交付的代码中的缺陷免费修复。

技术规格

Odoo 兼容性
Odoo 17, Odoo 18, Odoo 19
版本
企业版和社区版
许可证
许可证需要确认
Python 要求
Python 3.10+
数据库
PostgreSQL 12+

关于此产品

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.

你得到什么

  • 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

这是给谁的

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.

Advanced Access Rights Control 如何比较

标准伊科西尔定制建造竞争对手Odoo 原生
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

关于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.

申请报价

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)

申请报价

告诉我们您对 Advanced Access Rights Control 的需求,我们将发送价格、许可选项和量身定制的方案,通常在一个工作日内。

现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。