char_with_placeholder_field_to_check

Odoo's accounting has a review workflow built around a boolean field called checked on journal entries: entries needing attention show up under a To Check filter until an accountant marks them reviewed. Odoo 19 made that state visible directly in the entry lists, and this widget is how.

char_with_placeholder_field_to_check wraps the entry number column. It subclasses char_with_placeholder_field, inheriting its one trick, showing the placeholder as a muted value when the field is empty, and adds a single element: a rounded blue badge reading To review, rendered after the number when the entry is posted but not yet reviewed.

The condition is precise. The badge appears when record.data.checked === false and record.data.state === 'posted'. A draft entry never shows it, and neither does a record where checked simply was not loaded, because JavaScript's undefined is not strictly equal to false. On top of that the badge node carries groups="account.group_account_user", so only full accountants see it; invoicing-only users get a plain number column.

Review queues fail when the queue is a filter people must remember to open. Surfacing the To review flag inline, in the list accountants already work in, converts the review step from a separate chore into something you clear as you go. That is the entire point of this widget, and during a close it is a genuinely useful nudge.

For teams building their own review or approval flows on other models, quality checks, contract vetting, HR validations, this widget is the reference pattern for a list-level status nudge: a boolean on the record, an invisible companion field in the view, a badge gated by state and by access group. We reuse that structure regularly in custom Odoo workflow work because it is cheap, discoverable and does not touch the model's logic at all.

One managerial note: the badge is visible only to members of the Accountant group. If your reviewers are configured with lighter access rights, they will never see the nudge, and adoption of the review workflow will quietly stall. Check group membership before concluding the feature does not work.

How core uses it (Journal Entries list, Odoo 19)

<field name="name"
       widget="char_with_placeholder_field_to_check"
       placeholder="/"
       readonly="state != 'draft'"/>
<field name="checked" column_invisible="True"
       groups="account.group_account_user"/>
<!-- core's own comment: To be used for Reviewed badge display -->

Reusing the pattern on a custom review flow

<field name="reference" widget="char_with_placeholder_field_to_check" placeholder="/"/>
<field name="checked" column_invisible="True"/>
<field name="state" column_invisible="True"/>

The field names are not configurable: the template reads checked and state literally, and the state must be the string posted. A custom model must mirror those names and values, or you subclass the template with your own condition.

Two implementation details make this widget more interesting than its size suggests.

The badge lives in the base widget's template. The component class sets static template = "account.CharWithPlaceholderField", the base template, not a template of its own. The badge arrives through a t-inherit with t-inherit-mode="extension", which modifies account.CharWithPlaceholderField itself rather than deriving a new template. The practical consequence: any usage of the base char_with_placeholder_field widget also carries the badge markup, and on the same Journal Entries screens core does use the base widget for the Number column of another list. Records there simply fail the checked === false test when the view does not load the field, which is the only thing keeping the badge from leaking. It is a fragile equilibrium worth knowing about before you add checked to a view that uses the base widget.

The strict comparison is the safety net. undefined === false is false in JavaScript, so a view that forgets the companion field degrades to a plain number column instead of spraying badges on every posted entry. The same strictness means a custom model whose review flag is named anything other than checked gets no badge at all.

And one for the code archaeologists: the file is named char_with_placeholder_field_to_check_to_check.js, the suffix pasted twice, while the directory has it once. Harmless, but a reminder that this corner of the codebase was assembled quickly, which fits how briefly it lived.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows is read from the public development branch, which remains unstable until feature freeze; we re-verify against the shipped release.

The widget is deleted. The entire char_with_placeholder_field_to_check directory is gone from the development branch. Both list views that used it now pass the plain char_with_placeholder_field widget, and the invisible checked companion line next to them is removed as well. The inline To review badge, as implemented here, has no direct successor in those views at the time of writing.

The base widget survives. char_with_placeholder_field continues to exist and even gains usages on the development branch, so only the badge subclass is affected.

If a customization references the widget name, an upgraded database will log a missing-widget warning and fall back to the default char rendering, number still visible, badge gone. Fold the swap into your Odoo 20 migration checklist rather than discovering it in production.