Odoo Changelog — 2026-07-17

Friday, July 17, 2026

268 changes

Branch: saas-19.4

3 changes

Bug Fixes(3)

Resolved issues and error corrections

[FIX] mail: fix stale disabled state in More Actions

PR #276992

Coresaas-19.4mail

The more() action helper caches the More Actions object and only refreshes its inner actions list, leaving disabledCondition unchanged. As a result, if the dropdown is created while disabled, it remains disabled even after the composer is re-enabled. Individual actions (e.g., Attach files) don't exhibit this issue because they use a dynamic callback `(({ owner }) => owner.areAllActionsDisabled)` that is evaluated when needed. task-6393956 --- I confirm I have signed the CLA and read th

Original PR description

The more() action helper caches the More Actions object and only refreshes its inner actions list, leaving disabledCondition unchanged. As a result, if the dropdown is created while disabled, it remains disabled even after the composer is re-enabled.

Individual actions (e.g., Attach files) don't exhibit this issue because they use a dynamic callback `(({ owner }) => owner.areAllActionsDisabled)` that is evaluated when needed.

task-6393956

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

Forward-Port-Of: odoo/odoo#276870

[FIX] sale,purchase: allow sale order confirmation with readonly product access

PR #276891

Coresaas-19.4purchasesale

Original PR description

Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Forward-Port-Of: odoo/odoo#276563
Forward-Port-Of: odoo/odoo#270067

[FIX] stock_account: fix remaining_qty for lot products

PR #276994

Coresaas-19.4stock_account

Original PR description

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#276690
Forward-Port-Of: odoo/odoo#272411

Branch: saas-19.3

6 changes

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_{cl,my,ro}{_edi_pos}: fix partner view after multi ID

PR #276991

Coresaas-19.3l10n_cll10n_my_edi_posl10n_ro

In previous refactor [1], we wrapped the "vat" field under a "vat_div" div. This broke some xpath depending on the "vat". This commit repair those views. [1]: https://github.com/odoo/odoo/commit/825e7c803a4effd601fb247c660416f1cc6d26d7 task-6382108

Original PR description

In previous refactor [1], we wrapped the "vat" field under a "vat_div" div. This broke some xpath depending on the "vat".
This commit repair those views.

[1]: https://github.com/odoo/odoo/commit/825e7c803a4effd601fb247c660416f1cc6d26d7

task-6382108

Branch: saas-19.2

11 changes

Bug Fixes(11)

Resolved issues and error corrections

[FIX] stock: Syntax error on forecast_details view

PR #276251

Coresaas-19.2stock

Issue: There is a missing closing curly bracket on line 67 in odoo/addons/stock/static/src/stock_forecasted/forecasted_details.xml (View) This PR corrects this error opw-6367046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274575

Original PR description

Issue:

There is a missing closing curly bracket on line 67 in odoo/addons/stock/static/src/stock_forecasted/forecasted_details.xml (View)

This PR corrects this error 

opw-6367046

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

Forward-Port-Of: odoo/odoo#274575

Branch: saas-19.1

2 changes

Improvements(1)

Enhancements to existing features

[IMP] l10n_fr_pdp: move e-invoicing details to chatter

PR #276902

Coresaas-19.1account_peppoll10n_fr_pdp

Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465

Original PR description

Move French e-invoicing technical statuses out of the main invoice UI and into the chatter.

The PPF status is kept available in debug mode for troubleshooting,
while regular users get a concise chatter summary with the PA status, PPF status,
and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter.

Task-6273270

Forward-Port-Of: odoo/odoo#276770
Forward-Port-Of: odoo/odoo#269465

Branch: saas-18.3

1 change

Bug Fixes(1)

Resolved issues and error corrections

[FIX] website: ensure overridden CTA buttons apply after install

PR #276744

Coresaas-18.3website

Original PR description

### Issue:
The 'Schedule an appointment' and 'Next Events' CTA buttons were not
updated even when their conditions were satisfied.

### Steps to reproduce:
- Install only Website.
- In the configurator, choose 'Schedule Appointments' as the main
  objective.
- Complete the setup and create the website.
- The CTA button remains 'Contact Us' instead of 'Schedule an
  appointment'.

### Reason:
The `get_cta_data()` method is overridden in specific modules to update
the CTA button based on conditions. However, it is called before those
modules are installed, so the overridden logic is never executed.

### Fix:
Ensure that `get_cta_data()` is called and the CTA button is updated
after the required modules are installed.

task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681)

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

Forward-Port-Of: odoo/odoo#261781

Branch: 18.0

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FIX] website: ensure overridden CTA buttons apply after install

PR #276726

Core18.0website

Original PR description

### Issue:
The 'Schedule an appointment' and 'Next Events' CTA buttons were not
updated even when their conditions were satisfied.

### Steps to reproduce:
- Install only Website.
- In the configurator, choose 'Schedule Appointments' as the main
  objective.
- Complete the setup and create the website.
- The CTA button remains 'Contact Us' instead of 'Schedule an
  appointment'.

### Reason:
The `get_cta_data()` method is overridden in specific modules to update
the CTA button based on conditions. However, it is called before those
modules are installed, so the overridden logic is never executed.

### Fix:
Ensure that `get_cta_data()` is called and the CTA button is updated
after the required modules are installed.

task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681)

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

Forward-Port-Of: odoo/odoo#261781

Rows:Rows per page:

10 25 50 100

4 / 11Page 4 of 11 · 268 days total

Steps to produce: --- - Install the `sales` module. - Create a product and `enable track inventory.` - Log in as user with only view access rights in products and also have the sales access rights. - Create a sale order containing product and confirm it. Issue: --- - An access error is raised during order confirmation. Root cause: --- - In [commit], to handle inventory tracking, the `qty_available` field was moved to `product.product`. Unlike before, this value is increased or decreased depending on the operation performed. - As a consequence, creating or updating a sale order triggers a write to this `qty_available` field on the related product. This write happens under the current user's permissions, so users who only have read access to products (but can create/edit sale orders) hit an `AccessError`, since they lack write access on `product.product`. Solution: --- - Use `sudo()` when accessing the required product quantity information to ensure the operation can be completed without requiring additional product access rights. The same issue also occurs when confirming a purchase order. [commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b opw-6290608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276563 Forward-Port-Of: odoo/odoo#270067

Version: --------- - 19.0+ Steps to Reproduce: ----------------------- 1. Install sale_management, purchase, stock modules. 2. Create a storable product with Tracking: By Lot, 3. Create two Purchase Orders, each for 10 units. Receive PO-1 → 10 units with tagged as lot-1 Receive PO-2 → 10 units with tagged as lot-2 4. Create two Sale Orders: SO-1 → deliver 2 units from lot-1 (validate) SO-2 → deliver 4 units from lot-2 (validate) 5. Open Inventory > Reporting > Stock, click "Total Value", then check the "Remaining Quantity" column Issue: ------- Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4) Cause: -------- When the "Remaining Quantity" column is computed, the following call chain executes: stock.move._compute_remaining_qty() → calls product.product._get_remaining_moves() → calls product._run_fifo_get_stack() ← HERE is the problem https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372 `_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot argument. Inside `_run_fifo_get_stack`, because no lot is given, it computes the stack size from the TOTAL product qty across all lots: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583 fifo_stack_size = 14 (10 received lot-1 + 10 received lot-2 − 2 delivered lot-1 − 4 delivered lot-2) It then builds a domain to find incoming moves with NO lot filter: https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607 https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618 ```Domain: [('is_in', '=', True), ('product_id', '=', X)] ↳ returns both receipts ordered: [lot-2 receipt (10 qty), lot-1 receipt (10 qty)] then walks this list consuming `fifo_stack_size = 14`: So it take: [move_lot1_receipt(10)] First Lot remaining_qty_on_first = min(10, 14) = 10 after consuming fifo_stack_size → 14−10=4 left → move_lot1 gets 4 ``` So back in `_get_remaining_moves`: qty_by_move = { lot-2 receipt → 10, ← wrong (should be 6) lot-1 receipt → 4, ← wrong (should be 8) } - The root cause: `_run_fifo_get_stack` is designed for products that have one shared FIFO stack. For lot-valuated products, each lot is an independent inventory layer. Running a single combined stack mixes both lots together, so the deductions (2 from lot-1, 4 from lot-2) are not attributed to the correct receipt moves — the algorithm just consumes from the oldest receipts first with no awareness of which lot was actually delivered. Fix: ----- `_run_fifo_get_stack` already accepts a `lot=` argument that: - sets `fifo_stack_size = lot.product_qty` (correct per-lot qty) - adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain so only the receipts that touched that specific lot are returned The only missing piece was calling it per lot instead of once globally. - With the fix, the stack for each lot is built correctly: lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8 ✓ lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6 ✓ --- opw-6311341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276690 Forward-Port-Of: odoo/odoo#272411

### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button based on conditions. However, it is called before those modules are installed, so the overridden logic is never executed. ### Fix: Ensure that `get_cta_data()` is called and the CTA button is updated after the required modules are installed. task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261781

[FIX] fleet: fix vendor bill vehicle association bug Bug reprod: Go to 19.2 or above 1 - Go to vendor bills. 2 - Create an invoice line add vehicle. 3 - Click to vehicle via the link 4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...) Bug cause: 1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function. 2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view. 3 - self.env.context is passed directly as a context 4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry" 5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case. 6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell. 7 - That's why the context of account_id is passed to the vehicle page as well. Bug solution: 1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones. task - 6385611 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276167

**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages. <img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" /> Steps to reproduce: 1. Open Voice & Video Settings. 2. Start the Voice detection sensitivity test. 3. Quickly click Stop immediately after clicking Test. 4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level. > [!NOTE] > this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt. This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it. This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped. Forward-Port-Of: odoo/odoo#275933

Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't. Reason: When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment. The website logo is served through a dynamic link (`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with. As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes. Fix: When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo. opw-6260496 Forward-Port-Of: odoo/odoo#273542

Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete. ### Steps to reproduce 1. Create many messages, ensuring some are hidden from a specific user via access rules. 2. Open the message list view as that user. 3. Pagination incorrectly shows a total matching the current page (e.g., "1-68 / 68") instead of the full count (e.g., "1-80 / 5000+"). 4. Because the system believes all records are displayed, the "Next" page button is disabled, leaving the user stuck on the current page despite more records existing in the database. ### Cause The `mail.message` model filters records in Python after fetching them from the database to enforce complex access rules. 1. The system queries the database for a batch of records up to the view's limit. 2. The `_search` method removes inaccessible records from this batch. 3. The web client receives fewer records than the requested limit. 4. Interpreting this as the end of the dataset, the web client skips the count query and displays the current batch size as the total. ### Fix Add `'force_search_count': 1` to the action context. This forces the web client to execute a separate count query to determine the total number of records, regardless of the batch size returned. opw-5425361

Branch: saas-19.4

Bug Fixes(3)

[FIX] mail: fix stale disabled state in More Actions

[FIX] sale,purchase: allow sale order confirmation with readonly product access

[FIX] stock_account: fix remaining_qty for lot products

Branch: saas-19.3

Bug Fixes(6)

[FIX] l10n_{cl,my,ro}{_edi_pos}: fix partner view after multi ID

Branch: saas-19.2

Bug Fixes(11)

[FIX] stock: Syntax error on forecast_details view

Branch: saas-19.1

Improvements(1)

[IMP] l10n_fr_pdp: move e-invoicing details to chatter

Branch: saas-18.3

Bug Fixes(1)

[FIX] website: ensure overridden CTA buttons apply after install

Branch: 18.0

Bug Fixes(2)

[FIX] website: ensure overridden CTA buttons apply after install

Branch: saas-19.4

Bug Fixes(3)

[FIX] mail: fix stale disabled state in More Actions

[FIX] sale,purchase: allow sale order confirmation with readonly product access

[FIX] stock_account: fix remaining_qty for lot products

Branch: saas-19.3

Bug Fixes(6)

[FIX] l10n_{cl,my,ro}{_edi_pos}: fix partner view after multi ID

Branch: saas-19.2

Bug Fixes(11)

[FIX] stock: Syntax error on forecast_details view

Branch: saas-19.1

Improvements(1)

[IMP] l10n_fr_pdp: move e-invoicing details to chatter

Branch: saas-18.3

Bug Fixes(1)

[FIX] website: ensure overridden CTA buttons apply after install

Branch: 18.0

Bug Fixes(2)

[FIX] website: ensure overridden CTA buttons apply after install

[FIX] pos_restaurant: fix common extra data for receipt and PDIS tickets

[FIX] html_editor: toolbar flicker on color hover in unbreakable node

[FIX] website: ensure overridden CTA buttons apply after install

[FIX] fleet: fix vendor bill vehicle association bug

[FIX] web: kanban: no crash if no group to scroll to

[FIX] mail: fix flaky inbox mark as read test

[FIX] mail: stale voice detection sensitivity after stopping test

[FIX] mail: include vapid_public_key in pushsubscriptionchange handler

[FIX] mail: correct push device partner check and previousEndpoint key

[FIX] base: show archived users assigned to user-defined filters

[FIX] l10n_fr_account: expose French 296/297 subaccounts

[FIX] sms: process SMS Queue Manager batch per api

[FIX] account_edi_ubl_cii: fix price amount import

[FIX] website_crm_partner_assign : lead mail check on oauth change during a password reset

[FIX] html_editor: wrong image size displayed for website logo

Bug Fixes(1)

[FIX] point_of_sale: close active overlays on screensaver trigger

[FIX] mail, account: ensure pagination works in message lists