text

Every notes box, description area and internal comment field in Odoo runs through this widget. It is the default renderer for Text fields, so it appears far more often than its 25 explicit XML mentions suggest: write fields.Text() on a model and this is what users type into.

The component wraps a textarea with the quality-of-life features users never notice until they are missing: the box grows as content grows instead of scrolling internally, browser spellcheck is wired up, translatable fields get the translation flag button, and fields configured for it get a placeholder, static or dynamic. In list views a separately registered list.text variant starts at a single row so table cells stay compact.

Less obviously, the widget also declares support for html fields, where it edits the raw markup with no rich-text editor, and, new in Odoo 19, for char fields.

Free text is where process detail actually lives: handover notes, delivery instructions, interview feedback. The widget-level decisions look small but shape data quality. A field that opens at two rows invites two sentences; a single-line box invites a fragment. Choosing rows deliberately on your key forms is free UX design.

The line_breaks option is the underrated control. Turned off, the field refuses the Enter key, which is precisely what you want for values that must stay single-line, reference strings, one-line summaries fed into reports, without giving up Text-field storage. Teams usually discover this option only after a report breaks on an embedded newline.

And if your templates use placeholder text to coach users, the dynamic placeholder can pull that coaching from another field on the record, per record type, a trick core uses in mail templating and almost nobody uses in custom modules because it is documented nowhere.

This widget is a first-class Studio citizen. Odoo Studio is available on Enterprise plans.

1. Open the form you want to change and click Studio in the top menu.

2. Drag Multiline Text from the New Fields section onto the form. Studio creates a Text field with this widget as its default rendering.

3. In the Properties tab, set a Placeholder to show example text until a value is entered, and a Help Tooltip for the question-mark hint.

4. To edit raw HTML on an existing Html field instead, select that field and set its Widget to Multiline Text; the official Studio docs describe this exact combination for disabling the HTML editor.

Tip: turn on developer mode before adding the field to set a clean technical name; Studio's generated x_studio_ names are unpleasant to reference from reports later.

Studio covers creating the field, the placeholder and visibility rules. Three things stay in view XML.

The starting height is the rows attribute on the view, which Studio does not expose. Two rows is the code default.

Blocking line breaks is the line_breaks option, also absent from Studio's properties panel.

Dynamic placeholders, where the gray hint text comes from another field, need two options wired together in XML, shown below. If these small refinements are stacking up on your forms, that is standard view customization work, quick for someone who does it daily.

Standard notes box, taller by default

<field name="description" widget="text" rows="5"/>

The rows attribute sets the starting height; the box still grows as users type.

Single-line behavior on a Text field

<field name="reference_note"
       widget="text"
       options="{'line_breaks': False}"/>

Enter is refused, so the stored value can never contain a newline.

Dynamic placeholder from another field

<field name="body_text"
       widget="text"
       options="{'dynamic_placeholder': True, 'dynamic_placeholder_model_reference_field': 'model_id'}"/>

Opens the placeholder picker against the model referenced by model_id, inserting expressions like {{object.partner_id.name}} at the cursor. This is the mechanism mail template bodies use.

Raw HTML editing on an html field

<field name="body_html" widget="text"/>

No editor, no sanitizer UI, just the markup in a textarea. Studio exposes the same thing as the Multiline Text widget choice on an Html field.

Reading the full component turns up behavior worth having on record.

Trimming belongs to the field, not the widget. On blur, the widget trims the value only if the field definition carries the trim flag, which char fields have by default in the ORM. Whether your users' trailing spaces survive is decided in Python, and this widget just obeys.

The declared option nobody reads. supportedOptions lists placeholder_field, and Studio-style tooling displays it, but extractProps never consumes it; the feature actually rides on dynamic_placeholder plus dynamic_placeholder_model_reference_field. If you set placeholder_field on this widget and nothing happens, that is why.

Autoresize has a floor. With line breaks on, the textarea keeps a minimum height of 50 pixels and starts at the rows value, growing from there. The list.text variant zeroes the floor and starts at one row, which is why long notes stay tidy inside list cells until clicked.

Char support is new in 19. The 18.0 file declares ["html", "text"]; 19.0 adds char, making text a legitimate widget for size-limited fields that want multiline entry. Remember the char field's size still caps the length.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We diffed this widget's file against the public development branch at the time of writing; the branch is unstable until feature freeze, and we re-verify after release.

No option changes: supportedOptions, supportedTypes and extractProps are byte-for-byte identical to 19, including the unread placeholder_field declaration and the undocumented dynamic placeholder pair. All movement is internal, the migration to the new Owl props and signals syntax, which affects JavaScript patches and nothing in XML.