many2many_tags_banks

A contact can have several bank accounts, and on an accounting-enabled database they matter twice over: for receiving payments and, more sensitively, for sending them. A supplier's account number being wrong or unapproved is the kind of mistake that moves real money to the wrong place.

This widget renders those accounts as tags on the contact form, which suits a short list far better than an embedded table. Each tag shows the account and an indicator for whether outgoing payments are allowed on it, taken from a boolean field you nominate through an option.

It also adds two behaviors around that display. Clicking through opens the full bank account list for the partner, and when the widget mounts it saves the contact if there are unsaved changes, so that a partner being created inline from an invoice exists as a record before anyone tries to attach a bank account to it.

The outgoing payment flag is a control, not a decoration. Marking an account as not allowed for outgoing payments is how a finance team stops a supplier bank change from being used before it has been verified, which is the shape of most invoice fraud. Putting that state on the tag itself means the person choosing an account sees it without opening anything.

The inline save is the detail worth explaining to a team. Creating a supplier from a bill and adding their bank account in the same breath is common, and it only works if the partner has been written first. The widget does that automatically, which means the contact is committed earlier than a user might expect. On a form people treat as a draft, that is a surprise; on this particular form it is the only way the flow works.

The core usage

<field name="bank_ids" string="Bank accounts"
       widget="many2many_tags_banks"
       context="{'default_partner_id': id}"
       domain="[('partner_id','=', id)]"
       options="{'color_field': 'color',
                  'allow_out_payment_field': 'allow_out_payment',
                  'edit_tags': True}"/>

The domain and the default in context are what tie new accounts to this contact. The three options are the full configuration.

Without the outgoing payment indicator

<field name="bank_ids" widget="many2many_tags_banks"
       options="{'color_field': 'color'}"/>

Legal, and the tags render normally. The indicator simply has no field to read.

Locking creation from the tag input

<field name="bank_ids" widget="many2many_tags_banks"
       options="{'allow_out_payment_field': 'allow_out_payment',
                  'no_quick_create': True}"/>

Inherited from the tags widget. Useful where bank accounts should only be created through their own form, with validation.

The class extends the color-editable tags field and replaces the component that renders the tag row with its own subclass, so the template can show the outgoing payment indicator. The value for that indicator is added in the method that builds each tag's props, read from the related record's data under the field name you supplied.

Getting that field loaded is the job of the descriptor's related fields function. It takes whatever the base widget already injects and appends an entry for the named field, declared writable. That is what makes the value available on each tag without the view having to know anything about the bank account model.

The save on mount is short and deliberate. When the component mounts it asks whether the model's root record is dirty and, if so, saves it. The source comment explains the case exactly: creating a partner from a move, where the partner has to exist before it can be an account holder. It is worth knowing that this fires on mount, not on interaction, so simply opening a form with unsaved changes and this widget on it will commit the record.

One curiosity in the Odoo 19 file, harmless but odd: the class spreads its own static components list inside its own class body. Because static inheritance resolves that before the field is assigned, it evaluates to the parent's components, which is what was intended. The development branch rewrites it to the conventional form that says so directly.

The list action is plain: it builds a window action for the relation with a list and a form view, applies the field's own domain, and opens it in the current breadcrumb rather than a dialog, so a user reviewing bank accounts gets the full model with its own filters.

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

The base changes. On the development branch the widget extends the plain tags field rather than the color-editable one, which means the color-picking behavior that comes with that base is no longer part of this widget.

The tag rendering is rebuilt. Instead of subclassing the tag row component, the development branch defines a small dedicated bank tag component built on the shared badge tag, with an explicit prop list including the outgoing payment flag. The indicator itself and the option that feeds it are unchanged, and so are the save on mount and the list action.