Wednesday, February 18, 2026
7 changes · 19.0
Resolved issues and error corrections
This fix preserves the session information sent with IoT scale and generic device requests. It prevents failed acknowledgements from the Odoo server, helping connected devices complete their operations reliably.
Original PR description
Before this commit, `session_id` was lost during scale operations because `ScaleDriver` overwrote `self.data` instead of updating it, erasing the context. Additionally, the generic Driver class stored the ID as "owner", causing a TypeError on the server which expects "session_id". After this commit, `ScaleDriver` uses `.update()` to preserve the session context, and `Driver.action` correctly uses the key `session_id` in the response payload. This ensures requests are properly acknowledged by the Odoo server. Backport of #245048 opw-5485278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where a project dashboard could keep showing manufacturing details after a manufacturing order was removed from the project. This ensures project reporting reflects the latest manufacturing order updates and avoids misleading stale information.
Original PR description
**Steps to produce:** - Install `project_mrp_account` and `sale_management` with demo data. - Create a `Service` product with `Create on Order as Project`. - Create and confirm a Sales Order using…
**Steps to produce:** - Install `project_mrp_account` and `sale_management` with demo data. - Create a `Service` product with `Create on Order as Project`. - Create and confirm a Sales Order using that product. - Go to `Manufacturing Orders`, open the first MO, and in `Miscellaneous`, set the `Project` to the newly created one. - Click on Produce All on MO. - Open the Our Project > Dashboard (via 3 dots) > Manufacturing details show correctly. - From embedded actions, go to Manufacturing Orders. - Edit the MO and remove the Project value in Miscellaneous. **Issue:** - The project dashboard still shows the Manufacturing details even after the project is removed from the MO. **Root cause:** - In [1], the method `_account_analytic_entry_move` was removed. As a result, removing the project value from the MO no longer updates the analytic lines. - And we use the analytic line data for showing the MO data on the project dashboard, so stale analytic lines cause the dashboard to continue displaying Manufacturing details. **Solution:** - In [2], the method `_create_analytic_move` was introduced. - When `_create_analytic_move` is called, it internally calls `_prepare_analytic_lines` and super calls. - At [3], the `_prepare_analytic_lines` method is executed, which triggers `_perform_analytic_distribution`. - Inside `_perform_analytic_distribution` at [4], the existing analytic line are unlinked. - As a result, the analytic lines are properly removed. Since the project dashboard loads its data from analytic account lines (as explained [here]), the dashboard now reflects the correct Manufacturing data after the project value is removed. **Note:** - Before this commit (in 19.0), when a user set the project value on a Done MO, no analytic line was created for the product move. - In saas‑18.4, however, an analytic line was also generated for the product move. - After this commit, the analytic line is correctly created in 19.0 as well, ensuring consistent behavior with saas‑18.4. [1]: https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229 [2]: https://github.com/odoo/odoo/commit/35db55618fa70146afc89e662410aca95947e17b [3]: https://github.com/odoo/odoo/blob/2294f7174c52ebb95ec3ad1d120a896b694c6add/addons/stock_account/models/stock_move.py#L546 [4]: https://github.com/odoo/odoo/blob/2294f7174c52ebb95ec3ad1d120a896b694c6add/addons/stock_account/models/analytic_account.py#L53 [Here]: https://github.com/odoo/odoo/blob/2294f7174c52ebb95ec3ad1d120a896b694c6add/addons/project_mrp_account/models/project_project.py#L33-L36 **Before:** <img width="959" height="197" alt="before" src="https://github.com/user-attachments/assets/4f28ee12-3625-44c7-ada4-1f1d89344d94" /> **After:** <img width="959" height="172" alt="after" src="https://github.com/user-attachments/assets/5a45d266-6902-4ab8-9c88-3ed844207f8c" /> opw-5346505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale refunds now record refunded order lines as negative amounts. This prevents refund sales from inflating revenue figures and makes PoS reporting more accurate.
Original PR description
Before this commit, when creating a refund in the PoS, the order lines were created with positive price_subtotal and price_subtotal_incl. This let to incorrect data in the PoS reports. opw-5415639 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where opening a direct link to an older chatter message could fail to scroll to and highlight that message. This makes shared message links more reliable, especially in long conversations with many messages.
Original PR description
PR #223362 removes the early return for checking the origin thread in `highlightMessage()` while PR #234659 adds it again through the FW ports of a fix intended for mailbox (which has not been needed from 19.0 onwards). Since the auto-highlight of message is triggered when the thread is 1st loaded, i.e. has loaded 30 most recent messages, if the targeted message to highlight is not in the loaded messages, then the `highlightMessage()` call would be mistakenly and silently ignored by this early return. This trigger of `highlightMessage()` is done only once, hence the failed attempt to highlight the message. This PR removes reliance on the origin thread. Steps to reproduce the bug: - Send more than 30 messages in a chatter. - Copy the first message link and paste it into the browser to go to the message as a highlighted one. - Thread doesn't jump to the targeted message. task-5929780
This fixes a Spanish tax report configuration so EU goods purchases taxed at 0% are no longer counted in two places on the Mod 390 report. Businesses using Spanish localization will see more accurate annual VAT reporting and avoid duplicated amounts in the affected section.
Original PR description
How to reproduce: - Install the l10n_es module - Switch to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for 0% EU G, there is two tags for the mod 390, the one for grid 26 being wrong Before: <img width="818" height="447" alt="image" src="https://github.com/user-attachments/assets/0565802d-5d98-4e0f-9e08-50776f0a5aec" /> After: <img width="834" height="443" alt="image" src="https://github.com/user-attachments/assets/89696c83-7022-439d-adaa-d456c2dbadf8" /> opw-5867849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249022 Forward-Port-Of: odoo/odoo#247590
This fixes an issue where scheduled actions that timed out repeatedly could remain stuck and fail when run manually. The change ensures the timeout counter is properly cleared, helping automated jobs recover without administrator workarounds.
Original PR description
CronJobs timed_out_counter is not getting reset when reaching the CONSECUTIVE_TIMEOUT_FOR_FAILURE due to a transaction rollback. This commit introduces a fix to ensure only records with an actual…
CronJobs timed_out_counter is not getting reset when reaching the CONSECUTIVE_TIMEOUT_FOR_FAILURE due to a transaction rollback. This commit introduces a fix to ensure only records with an actual exception tuple pass through in method: 'method_direct_trigger'. Description of the issue/feature this PR addresses: When a cron job reaches the timeout threshold (timed_out_counter >= 3), method_direct_trigger crashes because the ListLogHandler filter matches log records that have exc_info = None. But the original filter only checked hasattr(lr, 'exc_info') which is true for all LogRecord objects. This caused a TypeError when attempting to unpack exc_info (None) on the next line, which rolled back the transaction and prevented timed_out_counter from being reset. Current behavior before PR: Clicking "Run Manually" on a timed-out cron (timed_out_counter >= 3) raises TypeError: cannot unpack non-iterable NoneType object, rolling back the transaction. The timed_out_counter is never reset, leaving the cron permanently stuck. Desired behavior after PR is merged: The filter correctly skips log records where exc_info is None (i.e., non-exception errors like timeouts). method_direct_trigger returns True, the transaction commits, and timed_out_counter is properly reset to 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Mark as Paid' button was hidden in the payroll system for users in Mexico when the l10n_mx_hr_payroll_account module was installed. This change ensures that Mexican users can correctly process and mark payroll payments, streamlining the standard payment workflow.
Original PR description
The "Mark as Paid" (action_payslip_paid) button on the hr.payslip form view [is hidden](https://github.com/odoo/enterprise/blob/19.0/hr_payroll_account/views/hr_payslip_views.xml#L39) when the l10n_mx_hr_payroll_account module is installed, making the standard payment flow confusing for users in Mexico. target: 19.0 task-5434674