code

Some fields hold code: QWeb templates, XML snippets, custom website head tags, computed expressions. Edited in a plain textarea they are unreadable and easy to break. The code widget replaces the textarea with an embedded Ace editor: line numbers, bracket matching, syntax coloring for the language you declare, and a dark theme that follows the user's color scheme.

The widget is deliberately thin. It declares one option, mode, which selects the Ace language mode; everything else is the shared CodeEditor component from the web core. Two details from the source are worth knowing up front: the default mode is qweb, and a mode of xml is silently remapped to qweb as well, because Odoo's QWeb mode is its XML mode with QWeb directives on top.

And if you have seen widget="ace" in older views: same widget. Both names point at one descriptor in the registry.

The practical value is guardrails for the semi-technical. Website managers pasting analytics tags into the custom head code, marketers adjusting a card template, consultants editing an automation expression: with syntax coloring, a typo that would silently break rendering is visible before saving.

The save behavior is also friendlier than it looks. The widget compares the editor content against the initial value and only marks the record dirty on a real change, and it commits the editor content when the form saves rather than on each keystroke, so autosave-style side effects do not fire while someone is mid-edit. For teams doing serious view or template development, the in-form editor is still a convenience, not an IDE; version control and proper deployment discipline remain the answer for anything that matters.

How core applies it (website custom code)

<field name="custom_code_head" widget="code" options="{'mode': 'xml'}"/>

A Python expression field

<field name="compute_expression" widget="code" options="{'mode': 'python'}"/>

Default mode (QWeb)

<field name="arch_snippet" widget="code"/>

Omitting the option gives you QWeb highlighting, which is the right default for template-ish XML.

The commit path is the part most customizations get wrong when they replace this widget. The component keeps the edited value locally and listens on the record model's bus for two events: the urgent-save signal (browser closing, navigation) and the local-changes collection that runs before any save. Only then does it push the value into the record, and only if the content differs from the value it started from. It also emits the standard dirty-flag event so the form's unsaved-changes indicator behaves. The consequence: server-side onchange logic on a code field fires at save time, not while typing, which is almost always what you want on large text.

Reading vs editing is driven by the standard readonly prop, and the initial value tracks record changes through a record observer, so switching records in a form keeps the editor honest.

Version notes from the source: 16.0 loaded the Ace library and its three mode files directly in the widget and registered only the ace name for text fields; 17.0 introduced the shared CodeEditor component, the code alias, the mode option and html-field support. Since 19.0 there is also code_ir_ui_view, a sibling registration wrapping the same descriptor with a view-editor variant used for ir.ui.view architecture.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below come from the public development branch, which can change until feature freeze; we re-verify after release.

The development branch adds a second option, lineWrapping, a boolean defaulting to false that soft-wraps long lines in the editor. Two details for the curious: the option name is camelCase, unusual for view options, and its declared label in the source currently reads "lineWrapping Lines", which looks like a copy-paste slip that may be cleaned up before release. The component also migrates to the new frontend props system as part of the framework-wide change. The mode option, both registrations and the save behavior are unchanged.