Most teams reach a point where Odoo's out-of-the-box security is either too coarse or too fiddly to manage safely. A salesperson can see margin fields they shouldn't; a warehouse user stumbles into Accounting menus; a junior can still click Validate, Cancel, or Post on documents that should be locked to a supervisor. Odoo core gives you res.groups, ir.model.access.csv, and ir.rule record rules — powerful primitives — but wiring field-level visibility, button-level restrictions, and multi-dimensional record rules by hand across dozens of models quickly becomes an unmaintainable sprawl of XML and CSV that breaks on every upgrade. This is where native Odoo runs out of road: it has the mechanisms, but no unified, admin-friendly control surface to govern who sees which menu, which field, and which action, without a developer editing source every time policy changes.

Generic Security Restriction is a made-to-order Odoo module that ECOSIRE designs, builds, and installs for you to close exactly that gap. Rather than hard-coding restrictions, we deliver a configurable security layer: a settings-driven model where administrators define restriction profiles that hide or read-only menus (ir.ui.menu), fields (via groups attributes and dynamic fields_view_get/get_views overrides in the ORM), and action buttons in both backend XML/OWL views and QWeb-driven flows. Under the hood we generate the appropriate res.groups, ir.model.access.csv entries, and parameterized ir.rule domains, then bind them to your restriction profiles so policy changes become configuration, not code. Field masking is enforced server-side in the models.Model read path — not just hidden in the UI — so the same rules hold over the XML-RPC/JSON-RPC API and in exports, closing the common loophole where a restricted field leaks through a report or an external integration.

Technically, the module is built to your model map. We audit the objects you need to govern, define compute-backed visibility helpers (@api.depends where a restriction is contextual), and apply record rules scoped by company, team, department, or any field you nominate — including multi-company setups where company_ids and company_id must be honored consistently. Menu and action restrictions are applied through group membership so they survive upgrades, and every override is written to be idempotent and version-aware across Odoo 17.0, 18.0, and 19.0 (we account for the get_views API changes and OWL view differences between those releases, and for Community vs Enterprise where an Enterprise-only view or action is in scope). We keep the footprint minimal and dependency-light so it coexists cleanly with your other apps and does not fight the standard upgrade path.

Because this is build-to-order, delivery starts with a short scoping call, not a download. We confirm the exact models, fields, menus, and actions in scope, agree the restriction profiles and who they map to, then build against a copy of your database, validate on staging, and install into production with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope, depending on how many models and profiles are involved and whether integrations or data migration are required. Pricing starts from $249 (indicative, single-company base scope); broader model coverage, multi-company record rules, deeper localization, and additional integration surfaces (API clients, external reports) increase the quoted scope. You receive a fixed written quote after the scoping call — never a surprise.