one2many

Every embedded table in Odoo, sales order lines, BoM components, invoice lines, journal items, is this widget. It is the default renderer for one2many fields, mounting a full list or kanban of the child records inside the parent form, with inline editing when the sub list allows it, an Add a line control, a pager past the page size, and dialogs for row editing when inline is off.

Under the hood it is the X2ManyField component, registered under both one2many and many2many. The field type flips the semantics: one2many children are created and deleted, many2many entries are linked and unlinked, with an Add control that opens a select dialog excluding already linked records. What renders inside comes from the sub views: the <list>, <kanban> or <form> declared inside the field element, or the target model's defaults when none are inlined.

Line editing is where ERP usability is won. The same one2many can be a friction free grid your sales team flies through, or a dialog maze they resent, and the difference is configuration: inline editable sub list for high volume entry, dialog forms when each child carries too many fields for a row, kanban mode when children are visual.

The options matter commercially because they encode process rules at the exact spot users would break them. Conditional domains on create and delete mean lines can be added while a quote is draft but not after confirmation, without a developer writing a constraint, and without training users to not do things the UI happily offers. Most teams do not know the domain form exists, so they either leave lines wide open or lock them harder than the process needs. The middle ground is one option away.

Odoo Studio (Enterprise) handles the standard setups.

1. Open the form in Studio.

2. Drag a One2Many field onto the form. It requires an existing many2one pointing back from the child model, which Studio prompts you to pick. For a fresh child table, drag Lines instead, which creates the child model arrangement for you.

3. Click the field and use Edit List View to shape the embedded columns, or Edit Form View to design the dialog that opens from Add a line.

4. General properties, visibility, readonly, required, apply from the Properties panel as usual.

Studio shapes the sub views; it does not reach the widget's behavior rules.

Conditional create and delete, the domain valued options that gate line editing by parent state, are XML only.

Making rows open in dialogs versus edit inline is the sub list's editable attribute, and the interaction between that, open_form_view and readonly states goes beyond what Studio exposes.

Filtering which records a many2many Add dialog offers is the field's domain, plus context defaults for records created from it. When embedded line behavior is the difference between a smooth rollout and a support queue, that is standard scope for an Odoo customization engagement.

Classic editable lines

<field name="order_line_ids">
  <list editable="bottom">
    <field name="product_id"/>
    <field name="quantity"/>
    <field name="price_unit"/>
  </list>
</field>

Lines locked once the parent leaves draft

<field name="line_ids"
       options="{'create': [('state', '=', 'draft')], 'delete': [('state', '=', 'draft')]}">
  <list editable="bottom">...</list>
</field>

Read only rows without making the field readonly

<field name="line_ids" options="{'write': False, 'create': False, 'delete': False}">
  <list>...</list>
</field>

Editable rows with an expand to form icon

<list editable="bottom" open_form_view="1">...</list>

The option pipeline. extractProps forwards the whole options dict as crudOptions, and useActiveActions reads six keys from it: create, createEdit, delete, link, unlink, write. Each non null value that is not a boolean is compiled as a domain and tested against the parent's evaluation context on every relevant render. The same helper ANDs in the sub view's own active actions, which is why both layers must agree. Two consequences follow directly from the source: the edit key is overwritten by the component with the parent record's edition state, so putting edit in options does nothing, and many2one options like no_create are simply never read.

Write is a real option. The embedded renderer's readonly flag is props.readonly || !activeActions.write, so 'write': False, or a domain, renders rows read only while the Add and delete controls follow their own options. That gating arrived in 19; the 18 renderer ignored write for readonly purposes.

Row opening rules. Rows open in a dialog only when the sub list is not editable. Editable lists can add the expand icon back with the list attribute open_form_view="1". The expand to full form path saves the parent first, and when that save fails, you get the danger notification asking to save changes first, a message users report as a bug and the source shows is a guard.

Mode differences. In many2many mode, Add opens the select dialog with already linked ids excluded through an injected domain, and kanban delete means forget the link, while one2many kanban delete truly deletes the child.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows is read from the public development branch, which is unstable until feature freeze, and this page is re-verified against the release.

The crud options move out of options. On master, extractProps builds crudOptions from the field node's attributes, picking create, delete, link, unlink and write, and no longer passes the options dict at all. In other words, options="{'create': False}" stops working and <field create="false"> becomes the way, aligning x2many fields with the attribute style the rest of the view language uses. Views leaning on option based gating, including the domain valued form, need review during the upgrade; the attribute path also accepts expressions, but the migration is not automatic.

The kanban compiler becomes the card compiler. The embedded kanban mode compiles through CardCompiler, part of the kanban to card rename rolling through the branch, which matters to anyone who patched the embedded kanban rendering.

This is the single most migration sensitive widget in this batch; if your forms encode line rules in options, put them on the Odoo 20 upgrade checklist now.