resume_one2many

Open any employee in a database with the Skills Management app and the left side of the form shows Resume: entries like Experience, Education and Internal Certifications, each with a timeline dot, a bold date range and a description. That block is one field, resume_line_ids, rendered by resume_one2many.

The widget subclasses the skills family's skills_one2many and swaps in its own list renderer. The renderer inherits from the shared skills list renderer but replaces the row template wholesale: instead of columns it draws a two-cell row, a timeline cell with the colored dot, and a content cell with dates, title, an optional course link and the HTML description.

Dates get special treatment. A line with no end date prints Current; a line flagged as a course drops the range's second half and prints the duration in hours instead. All of it reads record data by literal field names: date_start, date_end, is_course, duration, external_url, name, description.

The resume block turns the employee form into a living CV. HR teams use it to keep experience, education and certifications in one structured place, and because lines are typed and dated, the same data feeds skills reporting and internal mobility searches rather than sitting in an attached PDF.

The grouped Add buttons are a small workflow win: adding an Education line from the Education group header lands in a wizard with the type preset, one less dropdown for every entry. The e-learning integration goes further: completed internal courses append themselves as resume lines automatically, with the course link attached, so the CV grows without anyone typing.

For implementations, the message is that the resume is structured data with real reporting behind it. Companies migrating from documents to this block usually pair it with the skills matrix for a complete internal talent picture.

How core applies it (employee form)

<field mode="list" nolabel="1" name="resume_line_ids" widget="resume_one2many"
       context="{'default_employee_id': employee_id}">
    <list>
        <field name="line_type_id"/>
        <field name="name"/>
        <!-- date_start, date_end, description, is_course, duration, ... -->
    </list>
</field>

Core's own comment above this block explains the contract: the widget renders a custom list, and adding fields to the inline arch is what makes them accessible to it.

Reusing it on another one2many

<field mode="list" name="x_history_ids" widget="resume_one2many">
    <list>...same field names...</list>
</field>

Possible, but only if the target model mirrors the hr.resume.line field names, the renderer reads line_type_id, date_start and friends by literal name.

Two implementation details separate this widget from a styled list, and one of them is a bug.

The single-ref link bug. Since Odoo 18 the renderer forces every link inside a resume description to open in a new tab, a sensible hardening for user-pasted HTML. But the template puts the same t-ref on every row's description paragraph, and Owl's useRef binds a single element, so the mounted and patched hooks only ever process one row's links. Descriptions in other rows keep their original targets. The Odoo 20 development branch migrates to Owl's new Resource ref-collection API and loops linkRef.items(), which processes every row and quietly fixes the bug.

Grouping without group_by. The renderer's groupBy getter returns line_type_id unconditionally. There is no view-level control; the resume is always grouped by type, and the group header's Add button injects default_line_type_id so new lines land in the right section.

The ecosystem extends the row template. hr_skills_slides inherits the record row to prefer course_url over external_url for the link icon, which is how completed e-learning courses link back to the course. In 19 the survey-based extension from earlier versions is gone, and a new sibling appeared: internal_resume_lines, a separate view widget rendered above the field that fetches company-side timeline entries through an ORM call rather than from the one2many.

Registration history. Odoo 16 registered the bare component class, so descriptor-level features did not exist; 17 introduced the spread descriptor; 18 added the link retargeting; 19 only tweaked a wizard title. The Odoo 20 branch's Resource migration is the first behavioral change since.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026, and the development branch can still change.

The visible change is the Owl Resource migration: the renderer replaces its single useRef with a Resource collection and iterates items() when forcing description links to target a new tab. That turns the current one-row behavior into all-rows behavior, fixing the 18/19 quirk described above. The row templates, hardcoded grouping and field-name contract are unchanged, and the registration is untouched. We re-verify against the shipped release.