email

The email widget is the char field renderer for addresses. In readonly contexts the entire value becomes an anchor with a mailto: href, so a click lands in the user's mail client with the recipient prefilled. In edit mode on forms, the form.email variant renders an editable input with an envelope icon beside it carrying the same mailto link, editable and actionable at once.

The input is declared type="email", which buys exactly two things from the browser: a keyboard with the at sign on mobile, and the browser's built-in complaint when the text is not shaped like an address. Read the source and you find nothing else: no regex, no server round trip, no normalization. An address the browser accepts, or one written by an import or API call, is stored as-is.

That minimalism is a design choice worth understanding: Odoo treats deliverability as the mail stack's problem and rendering as the widget's problem. The widget's job ends at the mailto link.

Email addresses are the most clicked values in any CRM. The widget removes the copy-paste hop between seeing an address and writing to it, and on lists it turns entire columns into one-click outreach. Small friction, large volume.

The validation gap is the business-relevant part. The browser check stops typos like a missing at sign, but only in interactive editing; imports, integrations and quick-create paths bypass it entirely. If bounced mail costs you money, campaigns, invoicing reminders, portal invitations, the fix is a server-side constraint or a verification service wired into your entry flows, not trust in the widget.

Note also what clicking does: it opens the user's local mail client, outside Odoo. Teams that should send tracked mail from the record's chatter, where it lands in the customer history, may actually want that habit discouraged in favor of the chatter's Send Message, a training point more than a technical one.

Studio documents this widget for Text fields.

1. Open the view in Studio and select the field holding the address (a Text field).

2. In the Properties tab, set Widget to E-mail.

3. Click Close to leave Studio.

The widget has one option and Studio's generic properties cover the rest, so Studio coverage is essentially complete. What no view tool provides is real validation or deduplication of addresses; both live on the model or in the mail stack.

List column of clickable addresses

<field name="email" widget="email"/>

Form field with dynamic placeholder

<field name="email_from" widget="email"
       options="{'placeholder_field': 'partner_email'}"/>

While empty, the input shows the partner's address as gray placeholder text, useful on records that fall back to the partner address when their own is empty.

Server-side validation to close the gap

@api.constrains("email")
def _check_email(self):
    for rec in self:
        if rec.email and "@" not in rec.email:
            raise ValidationError("Invalid email address.")

The widget will never do this for you; a constraint catches every write path, including imports.

The base template has two branches. Readonly renders the anchor: the whole value, ellipsized when the column is narrow, with the mailto href built by simple concatenation. Edit renders the bare input, nothing else, which is what list rows use in editable lists.

The form variant inherits the base and appends the envelope: an anchor rendered only when the field has a value, with a tooltip reading Send Email. Small inconsistency collectors will enjoy this: the form envelope carries target="_blank" while the readonly link does not, harmless for mailto, but a genuine fingerprint of how the two templates evolved separately.

Because the href is plain concatenation, the widget happily links whatever is stored: an address with a display name, two addresses separated by a comma. The mail client receives it verbatim; what happens next depends on the client. One field, one address is the discipline that keeps this widget honest.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

Nothing user-facing changes. The single option, both templates' behavior and both the email and form.email registrations are unchanged; the component is ported to the new Owl props and signal refs. JavaScript patches importing the class need review; XML does not. We re-verify after release.