Odoo Changelog — 2026-07-07

Tuesday, July 7, 2026

4 changes · 17.0

Improvements(1)

Enhancements to existing features

[IMP] base: update symbol for Azerbaijani Manat (AZN)

Core17.0base

The Azerbaijani Manat (AZN) now uses its official currency symbol, ₼, instead of the previous symbol. This improves accuracy and consistency in currency display for users who work with Azerbaijani currency.

Original PR description

This commit updates the base currency symbol for the Azerbaijani Manat
(AZN) to its official Unicode character '₼'.

Related Upgrade PR: https://github.com/odoo/upgrade/pull/10107
Backport of: https://github.com/odoo/odoo/pull/262471

task-6112867

#currency#localization#AZN#display

Bug Fixes(3)

Resolved issues and error corrections

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

PR #123031

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

#grouping#datetime#hour labels#read_group#usability

[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

#invoice#pdf#rounding#display

This commit updates the base currency symbol for the Azerbaijani Manat (AZN) to its official Unicode character '₼'. Related Upgrade PR: https://github.com/odoo/upgrade/pull/10107 Backport of: https://github.com/odoo/odoo/pull/262471 task-6112867

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