many2one_binary

Storing a file as an ir.attachment and pointing at it with a many2one is a normal Odoo pattern. Rendering that field as a many2one is not: users do not think of their contract PDF as a record to look up.

This widget closes that gap. It renders the field as a file picker, wrapping the single attachment in a list so it can reuse the existing x2many binary component:

get files() {
    const attachment = this.props.record.data[this.props.name];
    return attachment ? [attachment] : [];
}

Uploading writes the new attachment's id, name and mimetype onto the field. Removing sets it to false.

It declares relatedFields for name and mimetype, so the file name and type are available for display without a second query.

This is the difference between an interface that matches how the data is modeled and one that matches how people think. The modeling is right: one file, stored once, linked by id. The old rendering was not.

Where it matters most is on records people fill in under time pressure, where being asked to search for an attachment record instead of dragging a file is the kind of friction that gets a process abandoned.

Restricting to documents:

<field name="contract_attachment_id" widget="many2one_binary"
       options="{'accepted_file_extensions': '.pdf,.doc,.docx'}"/>

Styling, which uses the class attribute:

<field name="contract_attachment_id" widget="many2one_binary"
       class="o_field_highlight"/>

This is ignored, and is the common mistake:

<!-- className comes from the class attribute, not from options -->
<field name="contract_attachment_id" widget="many2one_binary"
       options="{'class': 'o_field_highlight'}"/>

File uploads fail routinely: the file is too large, the server rejects the type, the connection drops mid-transfer. How a widget handles that decides whether a user loses their work.

This one treats a failure as information rather than an exception:

async onFileUploaded([file]) {
    if (!file) {
        return;
    }
    if (file.error) {
        return this.notification.add(file.error, {
            title: _t("Uploading error"),
            type: "danger",
        });
    }
    await this.props.record.update({ ... });
}

A rejected file produces a red notification carrying the server's own message and nothing else changes. The form stays open, the rest of the record is untouched, and the user can try again. No exception propagates, so nothing else on the page breaks.

Two smaller details worth knowing. isEmpty is hardcoded to () => false, so Odoo never treats the field as empty. The drop area renders even when nothing is attached, which is what you want for an upload target but means the field never collapses in a list.

And the class handling is unusual. Most widgets take styling through additionalClasses in the descriptor. This one reads it per-field from the XML attribute:

extractProps: ({ attrs, options }) => ({
    acceptedFileExtensions: options.accepted_file_extensions,
    className: attrs.class,
}),

One value from options, one from attrs, in the same three-line function. Putting class inside the options dictionary silently does nothing.

Introduced in Odoo 20. In Odoo 19 a many2one to an attachment rendered as an ordinary record selector, so a file-picker interface needed a custom widget.

The component is written against the Odoo 20 runtime throughout: useProps with the t type builder for props, and usePlugin(NotificationPlugin) rather than the service hook Odoo 19 would have used. Neither of those APIs exists in Odoo 19, so this widget could not be backported without rewriting it.