skill_match_gauge_field

Odoo 19's recruitment matching answers one question per candidate: how well do this person's skills and degree fit a given job? The number lives in matching_score, and this widget is how the form shows it: a half doughnut with the score printed inside the arc as a rounded percentage, the fixed caption Job Position Matching underneath, and, when known, the name of the job being matched against.

That job name is the widget's most unusual habit. At load it looks for matching_job_id in the record's evaluation context, and if present it fetches that job's name over RPC and displays it. The same context key drives the server compute: matching_score depends on the context, so opening candidates from a job's matching action scores everyone against that job, while opening an applicant directly falls back to the applicant's own position. Same field, same widget, different number per door you came through.

Technically it subclasses the standard gauge field and spreads its descriptor, overriding the rendering: value inside the arc with zero decimals and a percent sign, a thicker ring, the Chart.js title disabled in favor of the template caption, and a fixed tooltip reading This score reflects skills and degree match.

Recruiters shortlist faster when fit is a glance, not a mental spreadsheet. The gauge turns each application into an instant read, and because the score follows the matching context, the same talent pool re-ranks itself per vacancy: run the matching action from the Sales Manager job and every candidate's gauge rescores against that job's skill and degree requirements.

The green state is a deliberate signal, not decoration. The scoring formula lets strong candidates exceed 100 percent, each skill counts up to double the required level, so a green, over-full gauge literally means overqualified on the measured axes. Teams that know this read green as "interview for the senior variant of the role", which is exactly the conversation the widget exists to start.

The core usage, from the applicant form

<field name="matching_score" invisible="is_pool_applicant" nolabel="1"
       widget="skill_match_gauge_field"
       options="{'max_value': 100}"/>

Hidden for talent-pool applicants, full circle at 100 unless the candidate overshoots.

A dynamic maximum, using the working option name

<field name="my_score" widget="skill_match_gauge_field"
       options="{'max_field': 'my_target'}"/>

Remember it is max_field, not the declared max_value_field, and the max field must be loaded in the view.

The color logic is three lines that reward reading. Before clamping, the widget compares the raw value to the configured max: strictly greater switches the arc from the theme's primary variable to success, resolved at render time through the html editor's CSS variable helper, so rebranded themes recolor the gauge for free. Only afterwards does it stretch the max to contain the value, which is why an overshooting score renders as a completely full green arc rather than clipping. A zero-on-zero edge case forces the max to 1 so Chart.js still draws an empty track.

Server side, the formula in _compute_matching_skill_ids explains the numbers people question. The job total is the sum of required skill levels plus the expected degree's score times 100; the applicant total sums, per required skill, min(applicant level, required level x 2), plus the applicant's own degree score when the job expects one. The doubling cap is the entire overshoot mechanism: a candidate at level 80 against a required 30 contributes 60, not 30 and not 80. Unrequired skills contribute nothing, however impressive.

Two smaller source facts: the template namespace is hr_recruitment.SkillMatchGaugeField although the file ships in hr_recruitment_skills, a cross-module namespace borrow worth knowing when inheriting the template; and the base gauge descriptor declares no supportedTypes at all, so no console warning protects you from binding this to a non-numeric field, it simply charts garbage.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. We read the module on the public development branch at the time of writing, with the standard caveat that the branch is unstable and can change before release.

This widget is deleted, with no alias. Its replacement, gauge_chart, is registered in the view widgets registry, so it is a <widget> element, not a field widget, and it draws a multi-segment doughnut: a comma-separated score_fields attribute (core passes the new skills_score and degree_score computes) gives each component its own palette color, with the whole arc turning green once the total reaches the max. Its attributes fix the ancestor's quirk, max_value_field is read and working there, and the score fields must be loaded invisibly in the view, which core comments explicitly. Two leftovers we verified on the branch: the component instantiates the ORM service it never uses, and its template keeps a job-name line referencing a property that no longer exists, so the context job name display is effectively gone. Views using skill_match_gauge_field will log Missing widget and fall back to a bare number after upgrading. We re-verify once Odoo 20 ships.