float_toggle

float_toggle replaces the number input with a button showing the formatted value. Clicking it advances to the next entry in range, and past the end it wraps around to the first:

onChange() {
    let currentIndex = this.props.range.indexOf(
        this.props.record.data[this.props.name] * this.factor
    );
    currentIndex++;
    if (currentIndex > this.props.range.length - 1) {
        currentIndex = 0;
    }
    this.props.record.update({
        [this.props.name]: this.props.range[currentIndex] / this.factor,
    });
}

Two things follow from that code. The current value is matched against the range with indexOf, so a stored value that is not exactly in the range returns -1 and the next click lands on the second entry, not the first. And the factor is applied on the way in and divided out on the way back, exactly like float_factor.

This is a one-click field. It suits the case where a value is genuinely one of a few options and typing a number is overkill: a half day or full day, a confidence level of nothing, half or certain, a simple weighting.

The gain is speed in list views, where a user can set dozens of rows without opening anything. The cost is that a user cannot enter a value outside the range at all. If somebody eventually needs 0.75 and it is not in the range, they cannot type it, and the field looks broken to them rather than restricted.

Decide that up front: if the set of values is genuinely closed, this is a good widget, and if it is merely usually one of three, use a plain float.

Default behavior, cycling 0, 0.5 and 1:

<field name="unit_amount" widget="float_toggle"/>

A custom range with a factor, and the button kept clickable in readonly:

<field name="day_share" widget="float_toggle"
       options="{'range': [0, 0.25, 0.5, 0.75, 1], 'factor': 1, 'force_button': True}"/>

This option is accepted and ignored:

<!-- 'type' is declared by the widget but read by nothing -->
<field name="day_share" widget="float_toggle" options="{'type': 'anything'}"/>

The descriptor lists five supported options: digits, type, range, factor and force_button. Its extractProps returns four props:

extractProps: ({ attrs, options }) => {
    // Sadly, digits param was available as an option and an attr.
    let digits;
    if (attrs.digits) {
        digits = JSON.parse(attrs.digits);
    } else if (options.digits) {
        digits = options.digits;
    }

    return {
        digits,
        range: options.range,
        factor: options.factor,
        disableReadOnly: options.force_button || false,
    };
},

options.type appears nowhere, and the component's props declaration has no type entry either. Setting it changes nothing at all.

This matters beyond trivia. Anything that reads supportedOptions to build a configuration interface, including Odoo Studio and every third-party widget-options helper, will offer type as a real setting. A user will set it, see no change, and reasonably conclude the widget is broken.

The same block shows the digits precedence rule. If a view sets digits="[16, 2]" as an attribute and something inheriting that view later adds options="{'digits': [16, 4]}", the option loses silently. When a float_toggle refuses to change its precision, check for an attribute on the original view before changing the option again.

Odoo 20 adds one option, hide_trailing_zeros, which trims zeros to the right of the last significant digit so a value like 1.20 renders as 1.2. We verified this by diffing the float_toggle registration between the 19.0 and 20.0 branches.

Nothing is removed and the registration is otherwise identical, so existing float_toggle fields carry over unchanged. The dead type option is still declared and still unread in Odoo 20.

The same option arrived on statinfo in Odoo 20, which suggests a deliberate pass over numeric formatting rather than a one-off.