upgrade_selection

Some settings in Odoo exist in both editions but only function in Enterprise. Hiding them entirely on Community leaves users wondering whether the feature exists; showing them working leads to a setting that silently does nothing.

The convention Odoo uses is to show the control and intercept the change. This widget applies that to a selection: on Enterprise it is an ordinary dropdown, and on Community choosing a different value opens the upgrade dialog rather than applying it.

Its source comment states the intent plainly, that it is meant for configuration settings and shows an upgrade popup when the selection changes. The wrinkle is what happens afterwards.

Edition-gated settings are a product decision before they are a technical one, and the pattern here is the honest version of it: the option is visible, its unavailability is explained at the moment of interest, and the path to enabling it is offered. That converts better than hiding the feature and confuses less than letting it fail.

For anyone building on Community, the practical note is that this control cannot be made to work by changing the view. The check reads the edition from the build information, so the dialog appears regardless of what the setting is set to elsewhere.

The usual usage

<field name="self_ordering_mode"
       widget="upgrade_selection"/>

On Enterprise this is a normal dropdown. On Community, changing it opens the upgrade dialog.

The plain selection

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

No edition check, and the setting applies wherever it is chosen.

The boolean equivalent

<field name="some_flag" widget="upgrade_boolean"/>

The same pattern for a checkbox, and the widget this one mirrors.

The change handler is the whole widget. It checks a flag derived from the client-side build information and, when that says the database is not Enterprise, opens the upgrade dialog and returns without applying the change. On Enterprise it calls through to the standard handler.

The dialog is opened with a close callback, and that callback is where the widget's one quirk lives: rather than restoring the previously selected value, it assigns a specific literal string to the input element. That string is the default mode for this particular Point of Sale setting, written into the source.

Two consequences follow. Reusing the widget on a different selection would reset that field to a value that means nothing to it, and even on the intended field the reset is to the default rather than to whatever the user had before.

The edition check itself is worth noting for what it is not: it reads client-side build information rather than asking the server, so it is a presentation decision and not a security boundary. Whatever actually enforces the feature lives elsewhere.

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

Byte-identical. The file on the development branch matches Odoo 19 exactly, including the hardcoded reset value.