Odoo Changelog — 2026-07-07

Tuesday, July 7, 2026

3 changes · 17.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] knowledge: scroll methods return Promise since Chrome 150

Enterprise17.0knowledge

This fix preserves the expected behavior of file navigation in the Knowledge app after a Chrome browser change. It prevents newer Chrome versions from accidentally changing how scroll actions are handled, helping users keep a consistent experience.

Original PR description

Since Chrome 150, scrolling methods like `scrollIntoView()` return a Promise instead of `undefined`.

This commit adds block braces to ensure the action returns `undefined` and keeps the same behavior as before.

Reference:
- https://chromestatus.com/feature/5082138340491264
- https://chromium.googlesource.com/chromium/src/+/50f3e3d0a9bc02aad8b8161dbdd59046991dd2c7

runbot-941309

#browser compatibility#scrolling#Chrome

[FIX] base: use 24-hour format for read_group hour labels

PR #274662

Core17.0base

When records are grouped by hour, the labels now use a 24-hour format instead of a 12-hour format without AM/PM. This removes ambiguity in grouped lists and ensures users can clearly distinguish afternoon and evening records.

Original PR description

Description of the issue/feature this PR addresses:
When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`.

In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views.

Current behavior before PR:
A datetime value in the afternoon is grouped under a 12-hour label without AM/PM.

For example, records around `13:50` are displayed under:

    01:00 20 Mar

Similarly, a datetime value around `16:20` may be grouped under:

    04:00 26 Mar

This is ambiguous because the group header does not indicate whether the hour is AM or PM.

Example screenshot showing records around 13:xx grouped under `01:00`:
<img width="251" height="195" alt="image" src="https://github.com/user-attachments/assets/9c394063-f679-4faa-a045-2456cc452fb9" />


Desired behavior after PR is merged:
Hour-based datetime group labels should be unambiguous.

The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock.

For example:

    13:00 20 Mar
    16:00 26 Mar

This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

[FIX] account: Prevent invoice PDF from showing negative zeroes

PR #272576

Core17.0account

This change prevents invoices from showing amounts like “-0.00” when totals are effectively zero after rounding. It improves the appearance and clarity of PDF invoices so customers see a clean zero instead of a confusing negative value.

Original PR description

### Steps to Reproduce 1. Create SO with one line. Unit price $100 + 15% tax 2. Create a down payment for $100 and confirm 3. Create a down payment for the remaining $15 and confirm 4. Create an…

### Steps to Reproduce
1. Create SO with one line. Unit price $100 + 15% tax
2. Create a down payment for $100 and confirm
3. Create a down payment for the remaining $15 and confirm
4. Create an invoice for the original SO, the total is 0.00
5. Download the PDF and notice that the total is -0.00

### Description of the issue/feature this PR addresses: 
**Issue:** There should not be a negative sign on the invoice PDF. Because of rounding to accommodate the limitations of binary memory, there is a negligible negative remainder sometimes, which gets shown as -0.00.

**Solution:** Update the _compute_tax_totals method to check if the calculated totals and subtotals evaluate to zero using the currency's precision (is_zero()). If a value evaluates to zero, we explicitly force the amount to 0.0 and reformat it using formatLang, ensuring the PDF displays a clean 0.00

### Current behavior before PR:
Some cases cause there to be a negative zero on the invoice PDF.

### Desired behavior after PR:
No negative zeroes on the invoice PDF.

opw-6298712

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Since Chrome 150, scrolling methods like `scrollIntoView()` return a Promise instead of `undefined`. This commit adds block braces to ensure the action returns `undefined` and keeps the same behavior as before. Reference: - https://chromestatus.com/feature/5082138340491264 - https://chromium.googlesource.com/chromium/src/+/50f3e3d0a9bc02aad8b8161dbdd59046991dd2c7 runbot-941309

Description of the issue/feature this PR addresses: When grouping datetime fields by hour, `read_group` formats the group display label using `hh:00 dd MMM`. In Babel/LDML formatting, `hh` represents a 12-hour clock. Since the format does not include an AM/PM marker, afternoon/evening hours are displayed ambiguously in grouped views. Current behavior before PR: A datetime value in the afternoon is grouped under a 12-hour label without AM/PM. For example, records around `13:50` are displayed under: 01:00 20 Mar Similarly, a datetime value around `16:20` may be grouped under: 04:00 26 Mar This is ambiguous because the group header does not indicate whether the hour is AM or PM. Example screenshot showing records around 13:xx grouped under `01:00`: <img width="251" height="195" alt="image" src="https://github.com/user-attachments/assets/9c394063-f679-4faa-a045-2456cc452fb9" /> Desired behavior after PR is merged: Hour-based datetime group labels should be unambiguous. The hour grouping format now uses `HH:00 dd MMM`, so grouped datetime labels render using a 24-hour clock. For example: 13:00 20 Mar 16:00 26 Mar This fixes the datetime hour grouping label shown in grouped list views and other `read_group` consumers. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Steps to Reproduce 1. Create SO with one line. Unit price $100 + 15% tax 2. Create a down payment for $100 and confirm 3. Create a down payment for the remaining $15 and confirm 4. Create an invoice for the original SO, the total is 0.00 5. Download the PDF and notice that the total is -0.00 ### Description of the issue/feature this PR addresses: **Issue:** There should not be a negative sign on the invoice PDF. Because of rounding to accommodate the limitations of binary memory, there is a negligible negative remainder sometimes, which gets shown as -0.00. **Solution:** Update the _compute_tax_totals method to check if the calculated totals and subtotals evaluate to zero using the currency's precision (is_zero()). If a value evaluates to zero, we explicitly force the amount to 0.0 and reformat it using formatLang, ensuring the PDF displays a clean 0.00 ### Current behavior before PR: Some cases cause there to be a negative zero on the invoice PDF. ### Desired behavior after PR: No negative zeroes on the invoice PDF. opw-6298712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr