Odoo Changelog — 2025-12-11

Thursday, December 11, 2025

8 changes · master

Bug Fixes(8)

Resolved issues and error corrections

[FIX] l10n_mx_edi{_stock}: access to pos_order_ids

Enterprisemasterl10n_mx_edistockMEDIUM

This update resolves an issue preventing accountants from accessing invoices due to access rights restrictions within the system. The change allows accountants to process invoices by searching for records in sudo mode, bypassing the need for POS access permissions. This improves usability for a key user group.

Original PR description

The aim of this commit is to allow accountants to open the invoices
without getting blocked because they don't own the pos access rights.

Context:
It seems that the ORM is now checking the access rights over M2M which
creates a lot of access rights issues.

Before this commit:
The computation of `l10n_mx_edi_update_sat_needed` and the method
`l10n_mx_edi_cfdi_try_sat` would cause an access right issue.

Cause:
The method `_get_update_sat_status_domain` could be override in
l10n_mx_edi_pos and add a check on `<l10n_mx_edi.document>.pos_order_ids`
on which the accountant might not have access.
(The same issue would happens to a user processing a stock picking)

After this commit:
We search the domain in sudo mode and return unsudoed records allowing
the user to pursue its task.

opw-5263759
opw-5263824

Forward-Port-Of: odoo/enterprise#99590

#accounting#invoice#access rights

[IMP] social_facebook: fix the audience trend

PR #101769

Enterprisemastersocial_facebookMEDIUM

This update addresses a change in Facebook's data reporting, specifically the deprecation of the audience trend metric. We've temporarily adjusted our calculations to rely on total page follows, ensuring continued accurate reporting while we investigate a full solution. This change primarily impacts how we track page engagement.

Original PR description

Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend,…

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

#facebook#reporting#engagement

[FIX] pos_discount: global discount in split_bill_screen

PR #101280

EnterprisemasterposMEDIUM

This update resolves a problem where global discounts weren't correctly applied when splitting restaurant orders. The fix ensures discounts are consistently calculated and applied, regardless of whether the order is split, except during order transfers. This improves the accuracy of pricing and reduces potential errors for restaurant staff.

Original PR description

Steps to reproduce:
- Order some products in a pos restaurant
- Add a global discount
- Split the order

Issue:
The global discount can be chosen to be splitted.

Fix:
The first fix is to apply the global discount each time we add a product. The second fix is to hide the discount when splitting, and recalculate the discount on each splitted order afterwards execpt when tranferring an order.

task-5189067

Forward-Port-Of: odoo/enterprise#98222

#pos#discount#split bill

[FIX] account_accountant: prevent error when setting partner on statement line

PR #100799

Enterprisemasteraccount_accountantMEDIUM

This update resolves an error that occurred when users tried to link bank statements to invoices. Specifically, the system was failing when dealing with draft invoices that lacked an invoice date. The fix ensures the system correctly compares invoice and statement dates, allowing for accurate reconciliation.

Original PR description

Currently, an error occurs when a user sets the partner on a statement line. **Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)): - Install the…

Currently, an error occurs when a user sets the partner on a statement line.

**Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)):
- Install the `account_accountant` module.
- Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding
an `invoice line`.
- Go to the `Dashboard` and click `Last Statement` under the `Bank journal`.
- Create a `new statement line` with the `same amount` as the `invoice amount`.
- Click `Set Partner` and select the `same partner` used in the invoices.

`TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'`

After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2].

This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present.

[this commit]: https://github.com/odoo/enterprise/pull/98269

[1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585

[2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249

sentry-7063516380

Forward-Port-Of: odoo/enterprise#100576

#accounting#bank statements#reconciliation

[FIX] stock_barcode: merge moves by picking for batches

PR #101793

EnterprisemasterstockMEDIUM

This update fixes an issue where batch barcode scanning wasn't working correctly with multiple pickings. The system now properly handles moves from different pickings within a batch, ensuring accurate tracking of inventory. This improves the reliability of batch management for users.

Original PR description

Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of…

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

#stock_barcode#batch#picking

[WIP] voip: display keypad input cursor in mobile mode

PR #101623

EnterprisemastervoipMEDIUM

This update removes outdated code that was previously intended to display a cursor on the mobile keypad. The change directly addresses a usability issue, ensuring the keypad input cursor is correctly displayed for mobile users. This improves the overall user experience when using the VoIP feature.

Original PR description

task-5366961

#voip#mobile#usability

[FIX] voip: abort pending `parse_phone_number` rpc

PR #101897

EnterprisemastervoipMEDIUM

This update resolves an issue where quickly typing a phone number could result in outdated information being displayed. By canceling old requests, the system now consistently shows the most recent phone number entered by the user, ensuring a better user experience.

Original PR description

Previously, when the user typed quickly, an older RPC request could resolve after a newer one, causing stale data to overwrite the correct result.

This change ensures that any pending `parse_phone_number` request is cancelled (aborted) before a new one is started. This guarantees that the UI always displays the result corresponding to the user's latest input.

#phone number#user interface#reliability

[FIX] account_avatax*: never send records without lines

PR #101791

Enterprisemasteraccount_avataxMEDIUM

This update resolves an issue where AvaTax processes would fail if orders lacked at least one line item. This prevented accurate tax calculations and disrupted sales workflows. The change ensures that AvaTax only processes orders with valid line items, improving data accuracy and reliability.

Original PR description

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1],
2/ if you put the `end_date` of a subscription before the `next_invoice_date`,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Forward-Port-Of: odoo/enterprise#101643

#tax#avatax#order

The aim of this commit is to allow accountants to open the invoices without getting blocked because they don't own the pos access rights. Context: It seems that the ORM is now checking the access rights over M2M which creates a lot of access rights issues. Before this commit: The computation of `l10n_mx_edi_update_sat_needed` and the method `l10n_mx_edi_cfdi_try_sat` would cause an access right issue. Cause: The method `_get_update_sat_status_domain` could be override in l10n_mx_edi_pos and add a check on `<l10n_mx_edi.document>.pos_order_ids` on which the accountant might not have access. (The same issue would happens to a user processing a stock picking) After this commit: We search the domain in sudo mode and return unsudoed records allowing the user to pursue its task. opw-5263759 opw-5263824 Forward-Port-Of: odoo/enterprise#99590

Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics We fixed all metric except the audience trend, because we needed a fix rapidly, and we wasn't sure about unfollow. And indeed, `page_daily_follows` only count for positive value, unlike the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent of `page_fan_removes`... Example of data for a month: ``` page_follows 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 page_follows 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ``` So we now use `page_follows`, so the total value at a given time, and we look for the newest and oldest value (note that if we could do the same for `page_post_engagements`, then we could just make 2 APIs calls for the year stat). Task-5353390 Forward-Port-Of: odoo/enterprise#101625 Forward-Port-Of: odoo/enterprise#100275

Steps to reproduce: - Order some products in a pos restaurant - Add a global discount - Split the order Issue: The global discount can be chosen to be splitted. Fix: The first fix is to apply the global discount each time we add a product. The second fix is to hide the discount when splitting, and recalculate the discount on each splitted order afterwards execpt when tranferring an order. task-5189067 Forward-Port-Of: odoo/enterprise#98222

Currently, an error occurs when a user sets the partner on a statement line. **Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)): - Install the `account_accountant` module. - Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding an `invoice line`. - Go to the `Dashboard` and click `Last Statement` under the `Bank journal`. - Create a `new statement line` with the `same amount` as the `invoice amount`. - Click `Set Partner` and select the `same partner` used in the invoices. `TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'` After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2]. This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present. [this commit]: https://github.com/odoo/enterprise/pull/98269 [1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585 [2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249 sentry-7063516380 Forward-Port-Of: odoo/enterprise#100576

Steps to reproduce ----- - Enable batch pickings - Create a product - Create 2 receptions for the product (qty > 1) - Create a batch with the 2 transfers - Open the batch in barcode - Scan part of both pickings - Go back to the barcode main screen - Open the batch again > Both pickings have their demand = partially delivered quantity Cause ----- When leaving the page, we trigger https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68 in which we end up merging the moves together https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51 This has been added by 9753c24 (ade0bef in 17.0) The problem is that `_merge_moves` merges all of the moves into the first of `merge_into` https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088 This, however, doesn't make much sense for batches because the moves can be from different pickings. ----- Ticket: opw-5163740 Forward-Port-Of: odoo/enterprise#101630 Forward-Port-Of: odoo/enterprise#100940

Previously, when the user typed quickly, an older RPC request could resolve after a newer one, causing stale data to overwrite the correct result. This change ensures that any pending `parse_phone_number` request is cancelled (aborted) before a new one is started. This guarantees that the UI always displays the result corresponding to the user's latest input.

Calling Avatax without lines results in an error and blocks flows: ``` Odoo could not fetch the taxes related to MXXX - SOXXX/XXX. Please check the status of `Sales Order XXX` in the AvaTax portal. Transactions must have at least one line. ``` There are various cases this can happen: 1/ if `industry_fsm_stock` is installed, empty orders are confirmed [1], 2/ if you put the `end_date` of a subscription before the `next_invoice_date`, then none of the lines are considered invoiceable [2] and you get the error when viewing the subscription in the portal This commit filters out orders without lines. It's also possible to filter this on the level of the models by doing it in `_get_and_set_external_taxes_on_eligible_records()`. However, this means doing it separately for each model, and requires every implementer do it manually. [1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159 [2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475 opw-5214609 opw-5247727 opw-5311132 opw-5385960 Forward-Port-Of: odoo/enterprise#101643