In stock Odoo, every form view commits changes the moment a user leaves the record or triggers a save, and there is no built-in way to enforce a deliberate "review before you commit" step on the forms that matter most. That creates real exposure on high-value records — a mis-typed price on a sale order, an accidental partner-field overwrite, a half-finished manufacturing BOM saved mid-edit — where you actually want an explicit confirm/discard gate. Odoo core gives you exactly one editing behavior per form and no per-model or per-role way to make some records "instant" and others "protected." Teams end up training staff to be careful, which does not scale.

We build a configurable Edit Control layer that gives each targeted form view two selectable behaviors: an Instant mode that auto-saves field changes as they happen (useful for low-risk, high-throughput data entry), and a Manual mode that holds all changes in a dirty/pending state until the user explicitly clicks Save or Discard — with an unsaved-changes guard that blocks navigation, tab close, and record switching while edits are pending. Technically, this is implemented as an OWL client-side extension of the web form controller plus a small configuration model (models.Model with ir.model.access.csv and record rules) that maps which ir.model / view / user-group combination uses which mode. Defaults are declared in __manifest__.py data files so the behavior is reproducible across environments, and the mode can be resolved by a compute method (@api.depends) driven by model, view context, or the acting user's groups.

Because the behavior is data-driven rather than hard-coded, you can, for example, force Manual mode on account.move and sale.order for everyone while leaving crm.lead on Instant mode for the sales team — all without touching the underlying business logic or breaking standard workflow buttons, onchange, or server-side validation. The manual-save gate is purely a UX and data-protection layer: it never bypasses Odoo's ORM write(), security rules, or automated actions, and it works consistently whether the record is edited in the UI or updated through the XML-RPC/JSON-RPC API (API writes are unaffected — the gate is a UI construct). We support Community and Enterprise editions; the OWL and view-inheritance approach is edition-agnostic, and where Enterprise-only widgets are in scope we adapt the extension accordingly.

Delivery is build-to-order. We start with a short scoping call to confirm which models, views, and user groups need each mode, then we build against your Odoo version (17.0, 18.0, or 19.0), validate on a staging clone, run UAT with your team, and deploy with a documented rollback path. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope covering a small set of target models on one Odoo version); broader scope — many models and views, multi-company rollout, role-specific mode matrices, deeper integration with custom modules, or migration across Odoo versions — increases the quoted scope. You receive a firm fixed quote after the scoping call, never a surprise invoice.