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.