lunch_is_favorite

Odoo's lunch app shows today's menu as a grid of product cards. The grid is deliberately not editable: employees are ordering lunch, not maintaining a product catalog, so the kanban is declared with edit="0" and every field on the card is rendered read-only.

That creates a small conflict. Marking a dish as a favorite is one of the few things an employee should be able to do from that grid, and the standard favorite-star widget refuses to write when the view says read-only. lunch_is_favorite is the resolution: the same star, with its read-only decision taken from a different place.

Instead of asking the view whether this field is currently editable, it looks only at whether a readonly attribute was written on the field element in XML. In the lunch kanban there is none, so the star stays live even though everything around it is frozen.

Favorites are a small feature with a measurable effect on adoption. If an employee can mark the dishes they order every week, ordering becomes two clicks instead of a scroll through a supplier's whole menu, and the app gets used. Blocking that on a read-only grid would have quietly removed the reason to open the app at all.

The generalizable point for custom Odoo work is the pattern rather than the widget. Read-only views are a blunt instrument: they lock the whole record when the intent is usually to lock the business data and leave the personal, per-user flags alone. A tiny widget that opts one field out is often the cleanest answer, far cleaner than making the whole view editable and then defending it with rules.

The security note belongs with it. Because the star ignores what the view says, whatever protects the underlying field has to live on the server: access rights, record rules or an override on write. The widget only decides what the interface offers, never what the database accepts.

The core usage

<kanban js_class="lunch_kanban" create="0" edit="0">
  ...
  <field name="is_favorite" widget="lunch_is_favorite" nolabel="1"/>
</kanban>

edit="0" is the reason the widget exists. With the plain favorite widget the star would render and refuse to toggle.

Locking the star deliberately

<field name="is_favorite" widget="lunch_is_favorite"
       readonly="1"/>

A literal attribute is the only thing that locks it. Note that readonly="0" locks it too, because the attribute string is simply cast to a boolean.

Without immediate saving

<field name="is_favorite" widget="lunch_is_favorite"
       options="{'autosave': False}"/>

Inherited from the base star. On a kanban card this is rarely what you want, since there is no save button in sight.

The file has no component class at all. It exports a descriptor that spreads booleanFavoriteField and overrides extractProps to call the base extractor and then replace one key: readonly: Boolean(fieldsInfo.attrs.readonly).

To see why that matters, look at what the base extractor writes: readonly: dynamicInfo.readonly. That is the evaluated state, the one that accounts for the view's edit="0", the record being locked, and any readonly expression on the field. The base star's update method returns early when that prop is true, so on the lunch kanban the star would render at the right state and simply never change.

Swapping the source of that prop for the static attribute cuts the star loose from the view's opinion. It also introduces the coercion quirk. attrs.readonly is the raw XML attribute, a string, and every non-empty string is truthy in JavaScript. readonly="0", which reads to a developer as not read-only, produces true. So does an expression such as readonly="state == 'done'", which is never evaluated here and simply locks the star permanently.

Everything else comes from the base widget: the star and outline-star icons, the Add to Favorites and Remove from Favorites labels, the list column width of 20 pixels when the field carries no label, and the autosave option that defaults to true and makes the click a direct write.

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

Byte-identical. The file has not been touched on the development branch, which is notable in a cycle that rewrote most field widgets onto the new Owl props syntax. This one survives untouched because it declares no component and no props of its own, only a descriptor override.

Worth watching indirectly: any change to the base favorite widget's readonly handling would flow straight through here, since that is the single line this widget replaces.