many2many_binary

Where the binary widget stores one file in a column, this widget manages a pile: supporting documents on a leave request, attachments on a recruitment application, files on a mail group message. Each file is a real ir.attachment record, and the field is a many2many linking the record to its attachments. The widget renders each linked file as a card with its name, extension badge and a delete cross, image files get a real thumbnail, and an attach button opens a multi select file picker so a user can drop five PDFs in one action.

Uploads go through Odoo's standard attachment upload controller, and each returned attachment id is linked to the field one by one. A failed file surfaces a danger notification with the upload error while the rest continue.

The choice this widget forces is healthy: files become first class attachment records with their own access rules, storage handling and lifecycle, instead of blobs buried in a table column. That is what you want for anything users accumulate over a record's life, evidence on an expense, submissions on an application, signed annexes on an agreement.

Two operational notes from implementations. First, deletion here unlinks with one click and no confirmation dialog, so for compliance sensitive documents pair the field with archive style processes rather than trusting the UI to protect files. Second, because each upload is a real attachment, storage governance, filestore location, size discipline, cleanup of orphaned attachments, becomes an administration topic the moment this widget ships to a busy team. Both are process decisions, not widget settings, and they are cheaper to make before go live.

Standard multi file attachments

<field name="attachment_ids" widget="many2many_binary"/>

The model side: the relation must target ir.attachment

attachment_ids = fields.Many2many(
    "ir.attachment",
    string="Supporting Documents",
)

The field label doubles as the upload button caption, so name it the way the button should read.

PDF only, capped at three files

<field name="attachment_ids"
       widget="many2many_binary"
       options="{'accepted_file_extensions': '.pdf', 'number_of_files': 3}"/>

Why ir.attachment is not optional. The widget's upload path posts to /web/binary/upload_attachment, the controller that creates attachment records, then links each returned id into the field. Its card rendering depends on name and mimetype, which the widget declares as related fields so they load automatically, and downloads go through /web/content/<id>?download=true, an attachment route. Point the many2many at any other model and every one of those steps has nothing to work with.

How the cards decide their look. A file whose mimetype starts with image/ renders an actual thumbnail through /web/image, with a generic image icon as the error fallback; everything else gets Odoo's mimetype icon plus an uppercase extension badge derived from the file name. The image detection helper only entered the component in 19.0, one of the two functional differences from 18.

What readonly hides. In readonly mode the template drops the attach button and the per card delete crosses, leaving a clean gallery of downloadable files, which makes the widget perfectly usable on portal style read only forms.

What is not there. No drag and drop target, despite the multi select picker, no confirmation on delete, and no one2many support: supportedTypes declares many2many alone. Attachment lists needing per row metadata columns belong in an embedded one2many list on a model that wraps the attachment instead.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The statements below are read from the public development branch, which is unstable until feature freeze, and the page is re-verified once the release ships.

No functional changes are visible for this widget. The diff against 19.0 is a mechanical migration of the props declaration to the new schema system and a refactor of the file mapping code, with options, supported types, upload flow and template behavior unchanged. Both options survive with the same names.

That makes many2many_binary one of the stable corners of the upgrade: plan around the fields that do change, and let this one ride along. An Odoo migration assessment sorts your views into exactly those two piles.