many2many_avatar_employee_class

Regenerating work entries for a group of employees mostly succeeds, and occasionally does not: an employee whose contract has changed, or whose entries overlap something that cannot be recomputed. Telling the user which ones is the wizard's whole job.

This widget is how it tells them. The employees are shown as avatars, exactly as elsewhere in Odoo, and the ones that cannot be regenerated are marked. The list of problem employees is a second field on the wizard, and the widget is told its name through an attribute on the field element.

Beyond that flag it changes nothing. The avatars, their tooltips and the employee-specific handling all come from the widget it extends, and the tag list component it substitutes exists only to render the mark.

Batch operations that report failures as a list of names in a message are hard to act on, because the reader has to map names back to the people in front of them. Marking the failures in place, among the ones that worked, keeps the comparison visible.

The wider point for custom work is the mechanism rather than the widget. Passing a second field's contents as a per-tag flag is a light way to annotate any relational display, and it needs no server-side change beyond computing that second field.

What is worth planning for is that this particular screen does not survive the next version. If your payroll process depends on the regeneration wizard, that is a change to check before upgrading, and it is a bigger question than the widget.

The core usage

<field name="employee_ids"
       widget="many2many_avatar_employee_class"
       in_error="employee_in_error_ids"/>

Note that the flag field is named through an attribute, not through options. That is unusual in Odoo and easy to mistype.

The companion field

# on the wizard, holding the subset in error
employee_in_error_ids
# membership is tested per avatar

It has to be loaded on the record, since the widget reads it directly rather than declaring a dependency.

Without the flag

<field name="employee_ids"
       widget="many2many_avatar_employee"/>

The widget it extends: the same avatars, with no error marking.

The widget is thirty lines and does two things.

It substitutes the tag list component for a subclass whose only difference is its template, which is where the visual mark is drawn. And it overrides the method that builds each tag's properties, adding a flag computed by testing whether that employee's id appears in the current ids of the named field.

Testing against the field's current ids rather than a snapshot is what makes the marking follow the record. If the wizard recomputes which employees are in error, the avatars update without any extra wiring.

The extractor is the part to be careful with. It spreads the parent's extraction and then adds the flag field name, read from the field element's attributes. Because the descriptor does not declare it as a supported option or attribute, the only way to discover it is to read the source or a page like this one.

Its fate in the next version is not a rename. The wizard it serves is absent from the development branch, and so is the widget, so anything referring to either has to be reconsidered rather than repointed.

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 the page after release.

Both the widget and its wizard are gone. There is no registration under this name on the development branch, and the work entry regeneration wizard is no longer part of the module's wizard directory.

Because an unknown widget name falls back to the field's type, a custom view still naming it would render plain avatars without the error marking, and the underlying wizard would be missing entirely. Treat this as work to redo rather than to migrate.