account_move_statusbar_secured

In several countries an accounting system has to be able to prove that a posted entry was never altered afterwards. Odoo does that by hashing entries in sequence, so any later edit breaks the chain. An entry that carries such a hash is called secured.

The problem is visibility. Whether an entry is secured is a boolean that nobody looks at, on a form full of amounts and dates. This widget puts it where people already look: a padlock beside the Posted stage in the status bar, closed and green when the entry is secured, open and orange when it is not.

Everything else is the ordinary status bar. The same stages, the same clicking between them, the same visible-stage list. The widget inherits the standard component and edits its templates in three places so the lock appears next to the Posted label wherever that label is drawn: in the bar itself, in the dropdown on small screens, and in the current-value display.

Data inalterability is an audit conversation, and audit conversations go better with evidence a non-specialist can see. A finance lead who can open any entry and see a closed green padlock has an answer for the auditor that does not require a report or a developer.

The orange open lock is just as useful, because it is normal. Entries are secured in batches, so a recently posted entry legitimately shows an open lock until the securing runs. The distinction to explain internally is that orange means not yet secured, not tampered with.

The group gating matters commercially too. Core shows this widget only to users in the secured-entries group and the plain status bar to everyone else, which means the lock is deliberately not part of the everyday invoicing interface. If your client operates under one of the inalterability regimes, making sure the right people are in that group is part of the setup, not an afterthought.

The core usage

<field name="state" widget="statusbar"
       statusbar_visible="draft,posted"
       groups="!account.group_account_secured"/>
<field name="state" widget="account_move_statusbar_secured"
       statusbar_visible="draft,posted"
       groups="account.group_account_secured"/>

Two declarations of the same field, mutually exclusive by group. Only users who care about securing see the lock.

The field the lock reads

<field name="secured" invisible="1"/>

Required on any custom form, since the widget declares no dependency on it.

With a clickable stage list

<field name="state" widget="account_move_statusbar_secured"
       statusbar_visible="draft,posted,cancel"
       options="{'clickable': '1'}"/>

Inherited from the status bar. The lock only ever decorates the posted stage, whatever else is visible.

The class is eleven lines. It adds a getter for the secured flag and a getter for the currently selected item, and points at a replacement template. All the work is in that template, and it is a good example of how to extend a component whose label is drawn in several places.

A small named block renders a label plus, when the item's value is the posted stage, the padlock with its color chosen from the secured flag. The template then substitutes that block into three positions in the inherited status bar: the item labels in the bar itself, the labels inside the dropdown that small screens use, and the current-value display, which is replaced by first setting the item to the selected one and then calling the same block. Without that third substitution the lock would vanish exactly when the entry is posted and the bar collapses to a single value.

The comparison is against the literal posted value, so the widget is bound to the journal entry state selection rather than being a generic decorator. There is no option to move the lock to another stage.

The version detail worth recording is a small bug. In Odoo 18 the descriptor declared its supported type as state, which is not one of Odoo's field types. Supported types are what the framework uses when a widget is applied to a field of the wrong type and what developer tooling reads, so an invalid entry there means the widget was effectively unclassified. Odoo 19 corrects it to selection. Neither version prevents the widget from working when it is named explicitly in a view, which is why it survived a release.

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

Byte-identical. The widget file on the development branch matches Odoo 19 exactly, including the corrected supported type. The lock, the colors, the group gating and the template substitutions are all unchanged.