many2many_tags_email

Wherever Odoo asks "who should receive this", the recipient field needs more than names. The many2many_tags_email widget extends the Tags field for partner relations in mailing contexts: portal share dialogs, survey invitations, event reminders, follower additions. Each pill shows the partner with their email, the tooltip carries the address, and the autocomplete searches partners as usual.

Its defining trick is input parsing. Paste Jane Doe <jane@example.com>, the format every mail client exports, and the quick-create path splits it: name to the partner's name, address to its email field. A colleague pasting a CC line from Outlook creates correct partners without opening a single form.

Recipient UX is where external communication quality is decided. If inviting a new contact to a survey takes a detour through the Contacts app, users stop inviting new contacts, or worse, they create partners named jane@example.com with an empty email field, and the next mailing silently skips them. This widget's parsing exists precisely to keep partner data clean at the moment of entry.

Two behaviors have compliance-flavored consequences worth knowing. Quick-created recipients are real partner records the moment they are created, even if the user then cancels the wizard: the partner stays. And inline email edits through edit_tags save to the partner immediately, changing that partner's address everywhere it is used, not just for this message. Both are the right behavior for a shared address book, and both should be in your user training.

Recipients on a share wizard, as portal ships it

<field name="partner_ids"
       widget="many2many_tags_email"
       placeholder="Add contacts to share the document..."/>

Recipients whose emails can be fixed inline

<field name="recipient_ids"
       widget="many2many_tags_email"
       options="{'edit_tags': True}"
       can_write="is_editable"/>

The pencil affordance appears only when the record's is_editable evaluates truthy. Corrections write straight to the partner.

Locked recipient list, no new partners

<field name="partner_ids"
       widget="many2many_tags_email"
       options="{'no_create': True}"
       domain="[('email', '!=', False)]"/>

Inherited Tags behavior: only existing partners that actually have an email address can be picked, which is the sane configuration for anything that will really send mail.

Three source-level details separate this widget from a themed Tags field.

Creation bypasses the pending-record machinery. The overridden quick create calls orm.create("res.partner", [{name, email}]) and then links the new id into the relation. The partner therefore exists server side instantly, unlike standard tags quick-create which can ride along with the parent record's save. The same parsing feeds the Create-and-Edit dialog through a creation context that pre-fills default_email.

The widget declares its data needs. It extends relatedFields with email (marked writable, which is what makes inline fixes possible) and name. That is why every pill can show and edit addresses without the view listing subfields.

Display has a fallback chain. Pill text resolves name, then email, then display name, then a translated "Unnamed". If your recipient pills read as bare addresses, the partners have no names, and that is a data-quality signal, not a widget bug.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. These observations come from the public development branch, which can change until feature freeze, and this page will be re-verified against the release.

The interesting move is that edit_tags disappears again after one release: the development branch deletes the option, the can_write gate and the custom extractProps entirely. Recipient interaction moves into a new RecipientTag component with a live validity checker bus, so invalid addresses are flagged on the pill itself rather than through an edit dialog.

Also visible: color_field is explicitly filtered out of the supported options, so recipient pills stop pretending they can be colored, and the click-popover code is replaced by the new tag component. If you built anything on 19's edit_tags, plan for its removal.