work_permit_upload

An employee's work permit is a document with an expiry date and a compliance meaning, and it sits on the employee form among fields that are mostly text. Rendering it as a generic file input makes it look like an afterthought.

This widget gives it its own presentation. It is the standard binary file field with a different template, so the upload control looks like part of the HR form rather than a generic attachment box.

Nothing else is changed. The uploading, the clearing and the file name handling are all inherited, which is why the file is four lines long.

Work permit tracking is a compliance obligation in most jurisdictions, and the practical failure is not usually a missing feature but a form nobody fills in. Presentation is a real part of that: a field that looks like it belongs gets completed more often than one that looks bolted on.

The thing to plan for is the removal. The widget is absent from the development branch, which means the work permit presentation is being reworked. If your HR process depends on that field's appearance or on a customization of it, that is a change to check before upgrading.

The usual usage

<field name="work_permit"
       widget="work_permit_upload"
       filename="work_permit_name"/>

The file name attribute works exactly as on a plain binary field.

Restricting the file type

<field name="work_permit"
       widget="work_permit_upload"
       options="{'accepted_file_extensions': '.pdf,.png,.jpg'}"/>

Inherited from the binary field and unaffected by the template substitution.

The plain binary field

<field name="work_permit" widget="binary"/>

Identical behavior with the generic presentation.

There is one line of substance: a subclass naming a different template. The descriptor spreads the binary field's and swaps in that component.

Because the extractor is untouched, everything the binary field reads still reaches the component: the file name attribute, the accepted extensions option and the rest. That is worth contrasting with widgets elsewhere in Odoo that replace both a template and the extractor and silently lose the inherited configuration.

Everything visible, the layout of the upload control and whatever wording surrounds it, lives in the template rather than in this file.

Its removal on the development branch is therefore a statement about the template rather than about behavior: the work permit presentation is being handled differently, and the widget that existed only to name a template is no longer needed.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify this page after the release.

The widget is removed. There is no registration under this name on the development branch and the file is absent, so the work permit presentation is being reworked.

Because an unknown widget name falls back to the field's type, a custom employee form still naming it would render a generic file input. That is a cosmetic regression rather than a functional one, but it is worth catching before the upgrade.