A build-to-order Odoo module that gives you fine-grained control over the create, edit, and search options on many2one and many2many relational fields — configured per field, per view, without patching core. ECOSIRE scopes, builds, installs, and supports it for your database. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
应用清单
围绕您的工作流程构建
A build-to-order Odoo module that gives you fine-grained control over the create, edit, and search options on many2one and many2many relational fields — configured per field, per view, without patching core. ECOSIRE scopes, builds, installs, and supports it for your database.
无需自行搭建——由 ECOSIRE 构建、安装并提供支持的可用应用。
以一次性构建价格开始。我们在启动时与您共同确定范围。
ECOSIRE 在您的 Odoo 上构建、配置并安装。
约 2–4 周内上线，并提供上线后的支持期。
Anyone who manages an Odoo relational field knows the friction. On a many2one like partner_id or product_id, the dropdown always offers "Create", "Create and edit…", and inline editing — even when your data-entry team should only ever pick from an approved, controlled list. Elsewhere it is the reverse: you want a fast create affordance on a many2many tags field, but the default widget behavior fights you. Out of the box, these behaviors are baked into the web client's relational widgets, and toggling them field by field means either living with the defaults or writing bespoke OWL/JS overrides for every view. That is exactly where Odoo native runs out of road: options="{'no_create': True}" and its siblings exist, but they are scattered, inconsistent across widget variants, ungoverned, and give administrators no coherent way to reason about which fields expose which actions.
This is a made-to-order module that ECOSIRE builds for your database. It introduces a consistent, declarative layer over the standard many2one and many2many widgets so that create, "create and edit", inline edit, delete, and search-more (dialog) options can be switched on or off precisely where you need them. We deliver two complementary control surfaces: a clean, uniform options contract your developers set in XML views (honored identically by the list, form, and kanban renderers), and an optional per-field administrative configuration model (ir.model.fields-linked records with ir.model.access.csv and record rules) so that functional admins can govern behavior without editing views. Technically, we extend the web client's relational field components (OWL/JS assets registered through the web.assets_backend bundle in __manifest__.py) rather than forking them, so upgrades stay clean and the standard field APIs continue to work underneath.
Behavior can be made conditional and data-aware. Because the configuration is model-backed, options can respond to the record context, the user's groups (base.group_user, custom security groups), or a domain — for example, allowing inline creation of a contact only for back-office roles while presenting a locked picker to portal or shop-floor users. Where you need server-side guarantees rather than UI hints, we pair the widget controls with ORM-level @api.constrains or access rules so that a determined user cannot bypass the intent through the XML-RPC/JSON-RPC API. The module targets the standard many2one, many2one_avatar, many2many, many2many_tags, and many2many-checkbox widget families, and is validated against Community and Enterprise on Odoo 17.0, 18.0, and 19.0.
Delivery is build-to-order. After a short scoping call we confirm the exact fields, views, roles, and behaviors in a written scope, then build against a copy of your database, run UAT on a staging instance, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope, depending on how many fields and conditional rules are in play and whether Enterprise-only widgets are involved. Pricing starts from $249 (indicative, single-company base scope); wider field coverage, conditional/role-based rules, multi-company deployment, and server-side enforcement across custom models increase the quoted scope.
Configures many customer databases and is tired of hand-writing widget overrides per project. Wants a governed, reusable way to lock down or open up relational fields that survives upgrades across 17/18/19.
Owns data quality for a live database and needs to stop staff from creating duplicate partners, products, or tags on the fly — while still allowing trusted back-office roles to create records inline where it speeds work.
Cares about clean master data and controlled onboarding for shop-floor, portal, and junior users. Needs picker-only fields for some roles and full create/edit for others, enforced consistently.
Wants a clean `options` contract to declare relational-field behavior in XML instead of maintaining bespoke OWL patches, plus optional server-side guarantees against API bypass.
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| Fit to your fields and roles | Built to your exact fields, views, and security groups after a scoping call | Fully bespoke but you specify and manage everything | Generic toggles; you adapt your setup to its assumptions | |
| Configuration model | XML `options` contract plus optional admin-governed, secured config model | Whatever your developer builds and documents | Usually view attributes only, no governed admin layer | |
| Role / conditional behavior | Group- and domain-aware rules, different behavior per user role or record state | Possible, at bespoke build cost | Typically static, same behavior for all users | |
| Server-side enforcement | Optional `@api.constrains` + access rules so API calls can't bypass intent | Only if you build and test it | UI-only; API bypass remains possible | |
| Upgrade safety (17/18/19) | Assets-bundle extension, no core fork; migration offered | Depends on how it was written; you own upgrades | Varies; may lag new Odoo releases | |
| Testing & rollback | UAT on staging, automated tests, documented rollback plan | Only what you scope in | Self-install; you test it yourself | |
| Support & handover | Post-go-live window, docs, training, Git repo handover | Internal or your contractor's responsibility | Vendor forum / ticket support of variable depth | |
| Time to live | 2–4 weeks from confirmed scope, done for you | Depends on internal backlog and skills | Fast install, but limited to its fixed feature set |
This is a build-to-order module, not an instant download. After a scoping call we confirm the exact fields, views, and rules in writing, then build, test on staging, and deploy. Typical delivery is 2–4 weeks from confirmed scope, depending on how many fields and conditional/role-based rules are involved.
Pricing starts from an indicative $249 for a single-company base scope. The final figure is a fixed quote issued after a short scoping call, once we know the number of fields, whether you need conditional or role-based rules, server-side enforcement, and multi-company support. You approve the fixed quote before we build.
Every build includes a post-go-live support window for defect fixes and configuration tweaks. Because we extend the web client rather than fork it, the module is upgrade-friendly; we also offer paid support and migration when you move between Odoo 17.0, 18.0, and 19.0 or between Community and Enterprise.
The widget options govern the web UI. Where you need hard guarantees, we pair them with ORM-level `@api.constrains` and access/record rules so that create or edit intent cannot be bypassed through the XML-RPC/JSON-RPC API. That server-side enforcement is an explicit scope item we confirm during the scoping call.
Yes. We validate against both Community and Enterprise, and build for Odoo 17.0, 18.0, or 19.0 — you tell us your exact edition and series and we pin the delivered code to it. Enterprise-only widget variants are supported where your edition includes them.
Yes. You receive the full installable source and a Git repository handover with commit history and a tagged release. There is no license key or runtime lock — your team can read, extend, and maintain the module, and we hand over technical documentation to support that.
We extend the standard relational field components through the assets bundle rather than overriding core files, which keeps the module upgrade-safe and reduces conflict risk with other addons. Uninstalling cleanly restores stock widget behavior with no orphaned configuration data.
A build-to-order Odoo module that gives you fine-grained control over the create, edit, and search options on many2one and many2many relational fields — configured per field, per view, without patching core. ECOSIRE scopes, builds, installs, and supports it for your database.