question_page_one2many

A survey is a flat list of questions that users experience as a structured document: sections with titles, questions grouped under them, an order that matters. Odoo stores both in one relation, with a boolean on each row saying whether it is a page or a question. The widget's job is to make that single list read like two different things.

It does three separate things to achieve that. It swaps in a list renderer that knows about the section flag, so section rows render bold, take their own layout and let the title span the columns a question would fill. It routes creation differently, editing sections inline and opening questions in a dialog. And it forces the parent survey to be saved every time a question is created or edited, so that rules spanning several questions can be enforced right away instead of at the end.

That last piece is why the widget also installs a custom error handler. A failed save in the middle of an inline edit would normally raise Odoo's full-screen error dialog, which is a poor response to a missing question title. The widget converts it into a notification and quietly removes the row that could not be saved.

Sections are how a long survey stops being intimidating. Grouping twenty questions into four named blocks changes completion rates, and it changes them more than any wording tweak. The widget is what makes those sections cheap enough to use, since adding one is an inline row rather than a form.

The forced save is a trade rather than a free win. It means a survey author cannot build up several questions and then discard them all, because each one is committed as it is created. In exchange, contradictions are caught at the moment they are introduced, which for surveys matters because questions can act as triggers for other questions and a broken chain is hard to debug later.

For anyone reusing the pattern in custom work, the section idea generalizes well: any list where some rows are structure and some are content. Sale order lines already use a comparable arrangement. The renderer this widget installs is tied to survey field names, so a custom version means a small renderer subclass of your own, not just a widget attribute.

The core usage, trimmed

<field name="question_and_page_ids" nolabel="1"
       widget="question_page_one2many" mode="list,kanban"
       context="{'default_survey_id': id}">
  <list decoration-bf="is_page">
    <field name="sequence" widget="handle"/>
    <field name="title" widget="survey_description_page"/>
    <field name="question_type"/>
  </list>
</field>

Note the companion widget on the title column: it relies on an open-record helper that this widget publishes to its children.

The add buttons that produce sections

<control>
  <create string="Add a question"/>
  <create string="Add a section"
          context="{'default_is_page': True}"/>
</control>

The default_is_page key in the button's context is what makes the new row editable inline; without it the row opens in a dialog.

Reusing the widget on another model

<field name="line_ids" widget="question_page_one2many">
  <list>
    <field name="is_page" column_invisible="True"/>
    <field name="title"/>
  </list>
</field>

Possible, but the child model must genuinely carry fields named is_page and title, because the renderer names them literally.

The widget is a component subclass plus a descriptor. The subclass swaps ListRenderer for the survey renderer, defaults the list to editable at the bottom, and publishes an openRecord helper into the environment so child field widgets in the rows can request that a row be opened.

The save machinery is the substantial part. It takes the standard create and update helpers, wraps each one so that after the child row is written the parent record is saved as well, and rebuilds the open-record helper on top of those wrappers. If the parent save throws while creating, the widget deletes the offending row from the list before re-throwing a private error type. A handler registered globally in the error-handlers registry catches that type and shows the server's message as a danger notification titled Validation Error, which is what stops a missing title from raising a full error dialog.

Opening an existing row is guarded too. The override saves the parent record first and returns without opening anything if that save fails, on the reasoning that a form you cannot save is not worth opening. It then re-resolves the row from the current list by its database id, so the dialog edits the live record rather than a stale copy.

The renderer holds the section logic. It marks rows using the is_page field, adds a section list class to the table, applies bold and section classes to those rows, and merges columns between the title column and the next column it is told to keep, which in the survey case is the random question count. Its create override is the piece users feel: inline editing is enabled only when the create button's context sets the section default and the screen is not small, so on a phone every addition opens a dialog.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and the notes below may still change; we re-verify the page after release.

Behavior is unchanged. The section rendering, the forced parent save, the row cleanup and the Validation Error notification are all present on the development branch, and core still uses the widget on the survey form.

The internals move. The props are migrated to the new Owl schema syntax, and because the base x2many props are not yet exported as a shared schema the widget inlines them, with a source comment saying exactly that. The notification service is also resolved through a hook instead of the environment. Both changes matter only to JavaScript that patches this widget.