additional_identifiers_list

Different countries want different numbers on a contact: a VAT number here, a company registration number there, a tax identification number somewhere else. Modeling that as a column per identifier does not scale, so Odoo 20 stores them in a single JSON field and describes the available types in a second, server-computed JSON field.

This widget renders the editable list. Its sibling, additional_identifiers_button, provides the dropdown that adds a new type. Both extend a shared base and both declare supportedTypes: ["json"].

The source is explicit about its scope: a comment states it is only used for the additional_identifiers JSON field of the res.partner form view.

For any business trading across borders, this is the field that stops your contact form growing a new box every time you enter a new market. The set of identifiers a country needs is decided server-side and localization modules extend it.

The practical consequence for your team is that if an identifier your accountants need is missing from a contact, the fix is usually a localization module or a server-side change, not a view edit. Nothing in the XML controls which identifiers appear.

The standard pairing on a contact form. Both widgets act on the same field:

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

The metadata field does not need placing in the view. Both widgets declare it as a dependency, so Odoo loads it for them.

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 as part of a broader rework of how partner identifiers are stored. Odoo 19 has neither widget and no additional_identifiers field to render.

Both widgets are written against the Odoo 20 runtime. They use useProps for prop declaration and OWL 3's proxy for component state, neither of which exists in Odoo 19, so they could not be backported without rewriting.