many2one_tags_skills

Skills on an employee are child records: each one pairs a skill with a level and a type. Rendered as a table they take a block of the form; rendered as tags they take a line, which is usually the right trade on a profile.

This widget does that. It takes a child list and draws it as tags, each one clickable to open the underlying record in a dialog, with a delete action when the field is editable.

The name is misleading and worth flagging: the registration says many2one, while the class, the file and the behavior are all about a one-to-many. The name is what you write in a view, so it has to be used as-is, but it describes nothing about what the widget does.

Profile screens are a competition for vertical space, and skills are exactly the kind of data that is important to see and rarely edited in bulk. Tags give the overview; the dialog gives the detail when someone actually wants to change a level.

The pattern is reusable for any child list that is read far more often than it is edited: render compactly, open on demand. What is not reusable here is the widget itself, because its dialog title and template are specific.

The usual usage

<field name="employee_skill_ids"
       widget="many2one_tags_skills"/>

The name is the registered one, despite the relation being a one-to-many.

What a tag carries

text        # the record's display name
colorIndex  # from the record's color field
onClick     # opens the record in a dialog
onDelete    # only when the field is editable

All defined by the widget rather than inherited.

A full list instead

<field name="employee_skill_ids">
  <list editable="bottom"> ... </list>
</field>

A table, which is right where levels are edited in bulk.

Three things are defined in this widget rather than inherited, and each is worth knowing.

The tag properties are built from scratch: identifier, record identifier, text from the display name, color from the record's color field, an edit flag, a click handler that opens the record and a delete handler that only exists when the field is editable. Nothing is spread from a base, so nothing else appears on the tag.

The record opening is wrapped so that the dialog's title is set before delegating. That title is a fixed string naming skills, which is the clearest sign the widget is not general purpose even though its behavior would otherwise be.

And whether the opened record carries a reference back to its parent is decided from the widget attribute on the field, comparing it against the many-to-many name. That is how the same code serves both relation kinds, and it is the only place the many2one in the registered name has any echo at all.

One more oddity: the template it points at belongs to the recruitment skills module's namespace although the file ships in the skills module, so the two modules are coupled more tightly than the file layout suggests.

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.

Reworked alongside the tag components. The development branch changes this widget with the wider rework of how tags are built. The concept, a child list rendered as clickable tags with a dialog, is what to expect to survive.