peppol_non_focusable_selection

Odoo's selection widget renders a searchable menu. When that menu is used on a form, its search input is a real focusable element, which means it participates in the tab order and can capture the initial focus of a dialog. Usually harmless. On the Peppol registration wizard it is not.

That wizard asks for an electronic address scheme, which is a selection, and immediately after it the address itself, which is what the user has to type. The address field is marked as the default focus. Without this widget, the scheme dropdown's search input can take the cursor first, so the user starts typing into a filter box instead of the field they came to fill.

The widget solves it in the smallest possible way. It subclasses the select menu, inherits the search template, and sets a negative tab index on the input. Nothing else about the selection field changes: same values, same options, same saving behavior.

This is a one-line accessibility and flow fix, and it is worth reading as an example rather than a feature. Compliance wizards are exactly the screens where a stray focus costs money: users are already unsure what a Peppol scheme is, and a form that eats their first keystrokes reads as broken software rather than as an unfamiliar field.

The general lesson for custom Odoo work is that default_focus only wins if nothing else in the dialog grabs focus first. Searchable dropdowns, embedded editors and iframes all can. When a form has one obvious field to type into, it is worth checking the actual tab order rather than assuming the attribute is enough.

The core usage

<field name="peppol_eas"
       widget="peppol_non_focusable_selection"
       placeholder="Peppol ID" nolabel="1"/>
<field name="peppol_endpoint" nolabel="1"
       default_focus="1"/>

The pair is the point. The scheme dropdown steps aside so the endpoint input can claim the cursor.

Reusing it elsewhere

<field name="country_code"
       widget="peppol_non_focusable_selection"/>
<field name="vat" default_focus="1"/>

Nothing in the widget is Peppol-specific beyond its name and the module it ships in.

The base behavior, for comparison

<field name="peppol_eas" widget="selection"/>

Same values and same options, but the dropdown's search input stays in the tab order.

There are two classes and two templates, and together they add up to a single attribute. The field class subclasses the standard selection field and replaces one entry in its components map: the select menu becomes a subclass whose template redirects the search block to a locally inherited version. That inherited template's only edit is a negative tab index on the input.

The indirection exists because the search block is a separate template inside the select menu. Overriding the field's own template, which is what Odoo 18 did, means keeping a copy of a template that belongs to another component and re-checking it every version. Overriding the component and inheriting only its search block, which is what Odoo 19 does, is narrower and survives changes to the rest of the menu.

Worth being precise about what a negative tab index does: the element is skipped by keyboard tabbing and does not receive automatic focus, but it can still be clicked and can still be focused programmatically. So opening the dropdown with the mouse and typing into its filter still works exactly as before. Only the tab order changes.

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

Byte-identical. The widget file on the development branch matches Odoo 19 exactly, which is unusual in a cycle that touched most field widgets. It survives untouched because it declares no props of its own and only redirects a template.