skills_one2many

Install Odoo's Skills Management and every employee form gains a skills block: languages, technical skills, and certifications, each with a level and a progress value, grouped under their skill type. That block is one field, the employee_skill_ids one2many, rendered by this widget.

Structurally it is the standard x2many field component with two swaps. The list renderer is replaced by a SkillsListRenderer that inherits from a shared CommonSkillsListRenderer (the same family the resume block uses) and adds skills-specific behavior: fixed grouping by skill type, a check for whether any skill types exist yet, and a permission-gated timeline with a jump into the skills history report. The record dialog is replaced by a customized open flow that titles the wizard "Update Skills" and injects the right default employee.

Because the descriptor spreads the generic x2ManyField, everything else, crud gating, sub-view resolution, pagers, behaves exactly as on a normal one2many.

A skills matrix is only as useful as it is current, and this widget's design quietly pushes in that direction. The Update Skills dialog edits levels in place rather than making users manage rows in a grid, which is the difference between HR updating fifty employees in an afternoon or not doing it at all.

The permission logic matters for rollouts. The timeline and the Skills Report shortcut appear only to HR users and to managers viewing their own subordinates, computed at load from the HR access group and the employee hierarchy. Line employees see their skills without the historical analytics. If a manager reports "the report button is missing", the first check is whether the employee sits in their subordinate tree, not a bug hunt.

For recruitment, the same widget renders applicant skills, with the timeline suppressed through a context key since applicants have no history worth charting. That reuse is the point of the shared renderer family: one skills UI across employees, applicants, and resumes, so training carries over.

As core uses it on the employee form

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

Applicant skills without the timeline

<field name="applicant_skill_ids" widget="skills_one2many"
       context="{'no_timeline': True}"/>

The context key, not an option, suppresses the timeline block.

Restricting what users can do

<field name="employee_skill_ids" widget="skills_one2many"
       options="{'delete': False}"/>

The inherited x2many crud options apply normally, so removing deletion or creation works exactly as on a plain one2many.

Four behaviors come straight from the renderer's onWillStart and getters.

The permission model is client-computed. At load the renderer reads the current user's employee_ids, checks hr.group_hr_user, and runs a child_of search over hr.employee to build the user's subordinate list. The timeline getter then shows extras only when the viewer is an HR user or the form's employee is in that subordinate set. This is display gating, not security: the real protection is the model's access rules, and the widget just avoids dangling links.

Grouping cannot be configured. get groupBy() { return 'skill_type_id'; }. Custom grouping means subclassing the renderer.

The employee default handles the res.users case. When the parent record is a user rather than an employee, the Add flow resolves record.data.employee_id.id instead of the record id before injecting default_employee_id, which is why the same widget works on the user preferences form.

Odoo 18 saved harder than 19 does. In 18 the widget's save hook saved the sub-record and then immediately saved the parent record too, rolling the row back if that failed. Odoo 19 dropped the parent save, so skills edits commit with the form like a normal one2many, a real behavior change to retest after migration. The 18 dialog was also titled "Select Skills" and the report action pointed at the old hr.employee.skill.log model; 19 renamed the dialog "Update Skills" and moved the report to hr.employee.skill.history.report.

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

The widget's file is byte-identical on master. The moving part is upstream: the generic x2many component on the development branch stops reading crud permissions from the options dict and takes them from view attributes instead (create, delete, link, unlink, write picked from attrs). If that lands, an options="{'delete': False}" on your skills field would need rewriting as an attribute. The kanban-to-card renderer rename also lands in the same area.