project_task_progressbar

When a project task has allocated hours, Odoo computes progress as hours spent divided by hours allocated, a fraction between 0 and beyond 1 for overruns. project_task_progressbar is the widget that renders that fraction in task lists, and it makes two opinionated changes to the standard progress bar it extends.

It rescales. The base widget displays raw values; this one overrides currentValue to multiply by 100, so a stored 0.45 renders a 45 percent bar. That keeps the model's convention (fractions, which the decoration-danger="progress >= 1" conditions elsewhere in the views rely on) while displaying percentages.

It self-colors. The base bar is primary blue until overflow. This one is green below 80, orange from 80 to the maximum, and hands overruns to the inherited overflow class, which core's task views set to bg-danger. The result is the classic traffic light: comfortable, at risk, over budget.

A quiet third change: the file registers project_task_progressbar in the formatters registry as a percentage formatter, so the same field aggregated in a pivot or grouped list also prints as a percentage rather than a decimal.

For services companies, this bar is the earliest budget-overrun alarm that requires zero process.

A project manager scrolling the task list is not reading numbers; they are scanning for orange and red. Orange at 80 percent is the actionable moment, enough budget left to rescope, reassign or renegotiate, and that 80 percent threshold is the widget's real product decision. Red only confirms what already went wrong.

Two implementation notes from our projects. First, the bar only appears when tasks have allocated hours; teams that skip estimation get an empty column and blame the tool, so the rollout conversation is about estimating discipline, not XML. Second, the thresholds are hardcoded in the widget: if your risk appetite says orange at 60 percent, that is a five-line JavaScript override, not an option, and worth it for fixed-price work.

As the task list uses it

<field name="progress" widget="project_task_progressbar" optional="hide"
       options="{'overflow_class': 'bg-danger'}"
       groups="hr_timesheet.group_hr_timesheet_user"/>

Green under 80, orange to 100, red past it. The column ships hidden behind the optional toggle.

On your own fraction field

budget_used = fields.Float(compute="_compute_budget_used")  # stores 0.0 to 1.0+

<field name="budget_used" widget="project_task_progressbar"
       options="{'overflow_class': 'bg-danger'}"/>

Any 0 to 1 fraction gets the same traffic-light treatment; hr_timesheet must be installed.

The color getter rewards precise reading:

get progressBarColorClass() {
    if (this.currentValue > this.maxValue) {
        return super.progressBarColorClass;
    }
    return this.currentValue < 80 ? "bg-success" : "bg-warning";
}

The comparison runs on the scaled value. currentValue is already x100 here, and maxValue defaults to 100 when no max_value option is set. So the boundaries are: exactly 80 is already orange (the test is strictly less than 80), exactly 100 is still orange, and only past 100 does the super call return the overflow class.

The overflow color is inherited, not hardcoded. The super getter returns overflowClass, defaulting to bg-secondary gray; the red everyone associates with this bar comes from core's views passing overflow_class: bg-danger. Omit the option and your overruns render gray.

The formatter registration is easy to miss and easy to want. registry.category("formatters").add("project_task_progressbar", formatPercentage) means widget="project_task_progressbar" on a pivot or graph measure formats the fraction as a percentage too, the same dual-registry trick as im_livechat.rating_percentage, but this widget lives in both registries at once.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below are read from the public development branch and are not final until release.

No changes: the source file on master is byte-identical to Odoo 19, thresholds, scaling and formatter registration included. Watch the base progressbar page instead: on the development branch the base widget loses most of its options, and since this widget spreads the base descriptor, those removals will flow through to it at release. We re-verify against the shipped release.