additional_identifiers_button

This is the Add control for a partner's additional identifiers. It sits next to additional_identifiers_list, and both widgets point at the same JSON field: this one adds a type, the other renders and edits the values.

The dropdown is built by subtracting what the record already has from what the metadata offers:

get identifiersInDropdown() {
    const typesInUse = Object.keys(this.state.identifiers);
    return Object.entries(this.state.metadata)
        .filter(([k, v]) => !typesInUse.includes(k) && !v.display_optional)
        .map(([k, v]) => ({
            identifierType: k,
            label: v.label || k,
            help: v.help || "",
            sequence: v.sequence || 100,
        }))
        .sort((a, b) => a.sequence - b.sequence);
}

Selecting an entry writes the type with an empty value, which makes it appear in the list widget ready to fill.

The useful behavior here is the subtraction. A user only ever sees identifier types they have not already added, so the menu gets shorter as the contact gets more complete rather than presenting the same long list every time.

As with its sibling, nothing about which types exist is controlled from the view. If your team needs an identifier that is not on the menu, that is a server-side or localization question.

The standard pairing. Both widgets take the same field name:

<field name="additional_identifiers" widget="additional_identifiers_list"/>
<field name="additional_identifiers" widget="additional_identifiers_button"/>

Using the button alone is legal but unhelpful: types can be added and then never filled in, because the editing interface lives in the list widget.

Both widgets read the same companion field, declared as a dependency on each descriptor:

const METADATA_FIELD = "available_additional_identifiers_metadata";

const metadataFieldDependency = [{ name: METADATA_FIELD, type: "json", readonly: true }];

That metadata drives everything visible: each identifier type's label, its help text, its sort order and whether it is offered at all. None of it lives in the view, so a module adding a new identifier type changes what users see without touching any XML.

The display_optional flag is the part worth understanding, because it has three states rather than two:

1. Unset. The type is offered in the Add dropdown and appears in the list once chosen. This is the normal case.
2. "show". The type is always rendered in the list, empty and ready to fill, and is never offered in the dropdown because it is already there.
3. "hide". The type is not offered in the dropdown at all. It only appears if the record already has a value for it.

The dropdown filter reads !v.display_optional, so any value of that flag removes the type from the Add menu. That is the single rule behind both the show and hide behaviors.

One more detail that surprises people: clearing a value does not store an empty string, it removes the key entirely. onUpdateValue trims the input and calls delete this.state.identifiers[identifierType] when the result is empty. So a type the user blanks out disappears from the list unless its metadata marks it "show". Writes are debounced by 50 milliseconds, so rapid typing produces one record update rather than one per keystroke.

Finally, the JSON parsing is deliberately forgiving. parseJson catches any error and returns an empty object, which means malformed stored data renders as an empty widget rather than a broken form. Quiet, but worth knowing when a partner shows no identifiers and you expect some: check the stored value before the view.

Introduced in Odoo 20 alongside additional_identifiers_list. Odoo 19 has neither, and no additional_identifiers field for them to act on.

Both are written against the Odoo 20 runtime, using useProps and OWL 3's proxy for state, so neither can be backported without a rewrite.