This is a build-to-order module, not an instant apps.odoo.com download. After purchase ECOSIRE scopes your models and existing groups, then develops, tests, and installs it against your database. Typical delivery is one working week depending on how many custom models you run and how deep your current permission scheme is. Simpler databases land closer to two weeks; heavily customized instances with many bespoke models and multi-company record rules take longer. You'll get a firm timeline at kickoff, and we deliver to staging for sign-off before touching production.

Every build includes a two-week go-live support window for bug fixes, permission-model questions, and small adjustments as your roles evolve. Because you receive the full source, you own the module outright. We also provide a compatibility statement and upgrade notes, and offer paid version-migration and extended-support retainers when you move to a new Odoo major version. The module is built to Odoo 17/18/19 conventions, so upgrades are a controlled port rather than a rewrite.

Both. The security primitives it manages — ir.model.access, ir.rule record rules, security groups, and field-level view rules — exist in Odoo Community and Enterprise alike, on versions 17, 18, and 19. We tune the delivered build to your edition and to the exact modules you have installed, so the matrix reflects your real models rather than a generic catalog.

No — the module writes standard Odoo security records (the same ir.model.access rows and ir.rule domains a developer would create), so nothing goes 'outside' the framework. During the build we import your current scheme so the matrix starts from your real configuration, every change is logged with before/after values, and destructive edits (like removing delete rights on core accounting models or disabling a record rule) trigger a warning before saving. You can review the audit history and revert a change if a policy needs rolling back.

Yes. The visual record-rule builder lets you compose conditions — for example, records where the salesperson is the current user, or where a company/region tag matches the user's assignment — and it compiles them into a standard ir.rule domain behind the scenes. You choose whether the rule is global or group-specific and which operations (read/write/create/delete) it governs. No hand-written domain syntax is required, though the generated rule remains a normal, portable Odoo record rule.

For each group you can mark a field as hidden, read-only, or read/write — for instance hiding hr.employee.salary from a group or making sale.order margin read-only for support staff. The module enforces this at the view level and through access filtering so restricted users don't see the field in forms, lists, or exports. For fields that must be protected even against the XML-RPC/JSON-RPC API, we scope the enforcement accordingly during the build and confirm the intended threat model with you, so 'hidden in the UI' versus 'blocked at the ORM layer' is an explicit, documented choice rather than an assumption.