versions_timeline

When someone uploads a replacement for a document, the previous file does not disappear: it becomes a version. Those versions are child records, and rendered as a table they read like data rather than like history.

This widget renders them as a timeline instead. Each entry shows who created that version and when, with actions to restore it or download it.

Restoring swaps the version back into the current slot rather than deleting anything, and downloading fetches only that file, so neither action loses history.

Version history is one of those features whose value is entirely in the moment someone needs it, which is usually a moment of stress. Making it legible at a glance, rather than a table someone has to parse, is the difference between a useful safety net and a feature nobody trusts.

For document-heavy processes, contracts, drawings, policies, this is worth configuring properly. The default Documents setup covers most of it; what usually needs thought is who is allowed to restore.

The usual usage

<field name="previous_attachment_ids"
       widget="versions_timeline"/>

No options. The timeline draws itself from the relation.

What each entry offers

restore   # promotes this version to current
download  # fetches this version's file only
delete    # removes the version and its file

Each is a server call.

A plain list instead

<field name="previous_attachment_ids">
  <list> ... </list>
</field>

The same records as a table, without the actions.

The three actions are the widget. Everything else is layout.

Restoring calls a server method on the chosen version. It is a promotion rather than a copy: the current file becomes a version and the chosen version becomes current, so nothing is lost either way and the timeline simply reorders.

Downloading builds a link to the stored file for that version alone, which is what makes it possible to compare an old version against the current one without restoring first.

Deleting is the one that has to be a server call for a reason beyond convention. Removing the child record would leave the stored file behind, so the server removes both together. That is also why the action refreshes the record afterwards rather than trusting the browser's copy of the relation.

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.

Byte-identical. The file on the development branch matches Odoo 19 exactly, including all three action handlers.