Odoo's native access control is powerful but scattered. Permissions live across ir.model.access.csv grants, ir.rule record rules, security groups, and per-view attributes — and tightening any of them means editing XML, CSV and group definitions across modules, then upgrading the database. A business owner who wants to hide a menu from interns, make a field read-only for the warehouse team, or disable the "Confirm" button for junior sales staff usually can't do it without a developer. Studio-style tweaks don't cleanly cover buttons, statusbar transitions or field-level read/write in a governed, exportable way, and as a deployment grows nobody has a single view of "who can see and do what" — which is exactly what auditors and finance leads ask for.

This is a build-to-order module that ECOSIRE designs, builds, installs and supports specifically for your database — it is not an existing marketplace download. We build a centralized access management back-office where an administrator picks a user or a security group and, per model, toggles the visibility and access of menu items, individual fields (invisible / readonly / required), header and object buttons, and statusbar stages, alongside the create/read/write/unlink matrix. Under the hood we implement it against Odoo's own primitives rather than fragile monkey-patches: a configuration model (models.Model with @api.depends computes that preview the effective permission set), rules materialized into real ir.model.access and ir.rule records so the standard security engine still enforces them, and a lightweight ir.ui.view / fields_get layer that injects the field and button restrictions at view-render time. Everything is scoped by security group so it composes with your existing groups instead of replacing them.

Because the rules are expressed through native mechanisms, they hold across the Odoo web client, imported/exported data, and the XML-RPC/JSON-RPC API — a field you mark server-enforced read-only cannot simply be written by an external integration. The configuration is data (stored records, not code), so it survives module upgrades, can be exported/imported between databases, and is fully auditable: every change is captured in the chatter and mail.tracking.value history. We deliver the same feature set tuned to your edition, noting Community vs Enterprise differences (for example, some Enterprise-only models and the studio/approvals surfaces) so the governance layer covers exactly the apps you actually run.

Delivery is build-to-order. It starts with a short scoping call to inventory the models, groups and edge cases you need governed, after which we return a fixed written quotation and a staging build for your UAT before anything touches production. Typical delivery is one working week from confirmed scope, and we hand over installable source, documentation and a support window. Pricing starts from $999 (indicative, single-company base scope); the number of models governed, multi-company record-rule complexity, and the depth of API-level enforcement and integration testing increase the quoted scope.