many2many_tags_journals

Odoo 19's Multi-ledger feature lets accountants define journal groups such as GAAP or IFRS by excluding journals from a group. In a multi-company database those groups can be shared: the company_id on account.journal.group is optional, and an empty company means the group is visible to every company. That creates a display problem the standard Tags field cannot solve. Two companies routinely have journals with identical names, so a pill reading just Miscellaneous Operations is ambiguous.

The many2many_tags_journals widget is the fix. It subclasses the standard many2many_tags component and overrides exactly one rendering decision: if the parent group has no company set, every pill is rendered as Company - Journal, and the autocomplete dropdown appends the company name in muted italics after each suggestion. The moment the group is assigned to a company, both prefixes vanish and the widget is indistinguishable from the plain Tags field.

To make the dropdown annotation possible, the widget ships its own autocomplete subclass that adds company_id.display_name to the search specification, and its field descriptor extends relatedFields so every selected journal is fetched with its company. That is the entire delta: no new options, no new behavior beyond labeling.

If you run consolidated reporting across companies, Multi-ledger groups are how you keep local books and group books apart, and this widget is what keeps the setup screen honest. The failure mode it prevents is real: an accountant excludes what looks like the right journal from the IFRS ledger, but it belongs to the wrong company, and the consolidated report is quietly wrong until someone reconciles it weeks later.

For teams customizing Odoo, the widget is also a compact lesson in how to extend the Tags field correctly. It changes pill text by overriding getTagProps, enriches the dropdown through a custom Many2XAutocomplete, and declares the extra field it needs through relatedFields instead of hoping the view loads it. If you need journals, or any records, labeled by company elsewhere, copying this three-part pattern is the maintainable route, and it is the pattern we reuse in custom Odoo development work.

How core uses it (Multi-ledger list, Odoo 19)

<list editable="bottom">
    <field name="company_id" column_invisible="True"/>
    <field name="name" placeholder="e.g. GAAP, IFRS, ..."/>
    <field name="excluded_journal_ids"
        widget="many2many_tags_journals"
        options="{'no_create': True}"/>
</list>

Note the invisible company_id on the first line. It is not decoration: the widget's template reads record.data['company_id'].id directly, so the field must be present in the view for the widget to render at all.

Reusing it on a custom journal many2many

<field name="journal_ids"
       widget="many2many_tags_journals"
       options="{'no_create': True, 'color_field': 'color'}"/>
<!-- the model must have a company_id many2one, loaded in the same view -->

Because the full Tags descriptor is inherited, color_field and the creation-blocking options work unchanged. The relation should be account.journal; the company prefix logic assumes journal records carrying a company_id.

Three implementation details are worth knowing before you rely on or extend this widget.

The prefix decision reads a hardcoded field name. getTagProps checks this.props.record.data["company_id"] on the parent record. On a model without that exact field name the template expression crashes rather than degrading, which is why both core views load company_id even when the multi-company group feature is hidden.

The dropdown annotation and the pill prefix are implemented separately. The pill text comes from getTagProps; the dropdown company suffix comes from a template extension of Many2XAutocomplete that only renders when the group_company_id prop is falsy. Both react to the same condition, so they stay in sync, but a subclass overriding one must remember the other.

Selected journals are fetched with their company through relatedFields. The descriptor appends {name: "company_id", type: "many2one", relation: "res.company"} to the inherited list, and the custom autocomplete adds company_id.display_name to the search specification. That is why the company names appear without any extra query and without the view having to load anything on the journal side.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below are read from the public development branch, which is unstable until feature freeze; we re-verify this page against the shipped release.

The widget is deleted on the development branch. The entire many2many_tags_journals component directory is gone, and no alias is registered. Custom views that reference the widget name will fall back to the default many2many rendering with a console warning after an upgrade.

Its job moves server-side. The journal group views on the development branch use the plain many2many_tags widget with context="{'show_company_journal': True}", letting the journal's display_name computation produce the company-qualified label instead of the client. The same branch also reshapes the model, with the views built around an included_journal_ids field rather than excluded_journal_ids.

What to do about it: if you copied this widget's name into custom XML, plan to swap it for many2many_tags plus the context key during your Odoo 20 migration, and re-test any code that assumed exclusion semantics on journal groups.