mass_mailing_html

Designing an email is not the same as writing a document. The result has to survive mail clients that stopped supporting modern layout years ago, which is why marketing emails are built from a theme and a set of tested blocks rather than freely composed.

This widget is that design surface. It extends Odoo's rich text editor and adds a theme selector, a snippet palette and an iframe preview, so what you see is rendered in isolation from the rest of the interface. It also enables the code view, which the ordinary editor does not, because someone eventually needs to look at the markup.

Just as important is what it turns off. Checklists, video embedding, collaborative editing, embedded components and the sandboxed preview are all disabled, because none of them makes sense in something that will be delivered as email. The paragraph container is also pinned, so blocks stay predictable.

The commercial value of an in-product email designer is that campaigns stop needing a separate tool and a separate audience export. The content, the audience, the sending and the statistics all live on the same record, which is the whole argument for doing email marketing inside an ERP rather than beside one.

What makes it work technically is the second field. The editor writes a designed version, and the widget also produces an inline version, which is what the mail server actually sends. That separation is why the design stays editable while the delivered mail is flattened to what email clients accept.

The conditional blocks are the feature most teams underuse. Marking a block with an audience condition means one mailing can show different content to different segments, evaluated per recipient at send time rather than requiring two campaigns. It is worth building into a template rather than discovering later.

The core usage, trimmed

<field name="body_arch" widget="mass_mailing_html"
       class="o_mail_body_mailing"
       options="{'inline_field': 'body_html'}"/>

Two fields are in play: the one being edited holds the design, and the one named by the option receives the inline version used for sending.

Restricting the template list

<field name="body_arch" widget="mass_mailing_html"
       options="{'inline_field': 'body_html', 'filterTemplates': True}"/>

The second option narrows which mail templates are offered in the designer.

A conditional block

<div data-filter-domain='[["country_id.code","=","BE"]]'>
  Shown only to Belgian recipients
</div>

Before sending, the widget converts that attribute into a server-side condition evaluated per recipient. An unparseable domain becomes a condition that is always false.

The most interesting piece is the conditional block handling, because it explains how one mailing shows different content to different people. Before the mail is prepared, the widget walks every element carrying a filter domain attribute, parses it, and replaces it with a template condition that asks whether the recipient matches that domain. At send time each recipient is evaluated and the block is included or dropped.

The failure path is deliberately safe. If the domain cannot be parsed, the element is given a condition that is always false, so the block simply never appears rather than breaking the render or leaking to everyone. A source comment marks this whole routine as work to be moved into a proper plugin, which is a good signal that it will change again.

The extractor is the other half worth reading. It starts from the rich text field's own props, then forces a set of editor settings: checklists off, video off, the base block pinned to paragraphs, migration off, embedded components off, collaboration off, sandboxed preview off, and the code view on. None of those is exposed as an option, so a view cannot re-enable them, which is the correct choice for a surface whose output has to survive email clients.

The component itself carries considerably more: an iframe, a theme selector, a local overlay container for editor toolbars, and careful handling of prop updates so the active theme is computed just before the component is patched. That machinery is what makes the design surface feel separate from the form it lives on.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this is a large, actively changing file; treat these notes as direction only and check again after release.

The widget survives and continues to move. It is still registered and still used on the mailing form, and the development branch continues reworking its internals along with the rest of the editor stack.

The surrounding form changes more than the widget. On that branch the mailing's audience handling is redesigned, moving from a single saved filter to several dynamic lists, and the recipient domain moves to a savable domain widget. If you customize the mailing form, expect the form around this field to differ more than the field itself.