Daily updates from Odoo
Friday, January 9, 2026
10 changes · master
Resolved issues and error corrections
This update resolves an issue where dragging a CSV or Excel file to import bank statements resulted in an empty screen. Now, users can successfully import their bank statements, and imported records are displayed with relevant details like bank account, statement, and notes, improving the bank reconciliation process.
Original PR description
Before this commit: - If we drag and drop a CSV/Excel file to import a bank statement from the dashboard, we have an empty screen instead of imported records. After this commit: - Now we get all those newly imported records after dragging and dropping a CSV/Excel file of bank statement from the dashboard. - If the record is imported, then we add this information into the chatter: bank account, statement, reference, end-to-end_id, notes. task-5212807 Forward-Port-Of: odoo/enterprise#103512 Forward-Port-Of: odoo/enterprise#98843
This update prevents the loss of Starshipit delivery orders when label creation fails. Previously, a failed label attempt would delete the order, requiring users to restart. Now, users can correct data in Starshipit and retry validation, ensuring orders are preserved and streamlining the delivery process.
Original PR description
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the…
## Current behaviour: When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order. ## Expected behaviour: If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order. ## Steps to reproduce: 1. Validate a delivery order integrated with Starshipit. 2. Trigger a label generation failure (e.g., bad address). 3. Observe that the created Starshipit order is deleted. ## Cause of the issue: The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order. ## Fix: Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual. ## Additional note: The _() wrapper in the error line was removed because the Starshipit service has no env or language context. Since translations cannot be resolved there, Odoo raised a warning. Removing _() avoids this warning and keeps the error clean. opw-5306979 Forward-Port-Of: odoo/enterprise#103480 Forward-Port-Of: odoo/enterprise#101174
This update fixes an issue where the recurring price table wasn't displaying correctly when the 'one-time purchase' option was selected. The fix ensures the pricing table is shown accurately for both service and goods products, improving the user experience and ensuring accurate product pricing.
Original PR description
Currently, the recurring price table displays incorrectly when the user enables the one-time purchase option for a product. **Steps to produce:** * Install `website_sale_subscription` with demo data…
Currently, the recurring price table displays incorrectly when the user enables the one-time purchase option for a product. **Steps to produce:** * Install `website_sale_subscription` with demo data * Products > Car Leasing > Recurring prices > Enable Accept One-time * Go to that product's website page **Observed behavior:** The pricing table template [1] is appended inside the input radio button instead of replacing the entire pricing table. **Root cause:** * Initially, when the `sale_subscription_product_price` template is used, function [2] replaces the table inside `div` [3], which has the `plan_select` class. * But When one-time purchase is enabled, the template `subscription_one_time_sale` is used instead of `sale_subscription_product_price`. * In that template, `div` [4] does not have the `plan_select` class. * Because of this, the query selector [5] finds the first `plan_select` element inside `input` [6]. * As a result, function [2] renders the table inside that `input` element instead of the intended `div`. **Solution:** This commit ensures that: * One time purchase price is changed dynamically based on variants. * The pricing table is displayed correctly for both service and goods type products. * The radio button selection works correctly by adding classes to the template and modifying its interaction accordingly. | Before 'Service' type product page | After 'Service' type product page| |--------|--------| | <img width="1855" height="928" alt="image" src="https://github.com/user-attachments/assets/d662fbf5-cfce-45c5-b14c-043e982c63a6" /> | <img width="1851" height="933" alt="image" src="https://github.com/user-attachments/assets/8e510b27-6917-43bc-ac5d-b01ff1b187ad" />| | Before 'Goods' type product page | After 'Goods' type product page | |--------|--------| | <img width="1852" height="931" alt="image" src="https://github.com/user-attachments/assets/b9aa68e7-beef-413c-b99e-a71937e35e10" />| <img width="1851" height="932" alt="image" src="https://github.com/user-attachments/assets/d768edd9-2169-4d43-ac59-9893b55d5bcd" /> | [1]: https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/xml/pricing_view.xml#L21-L63 [2]: https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/js/variant_mixin.js#L32-L36 [3]: https://github.com/odoo/enterprise/blob/77423e62d5b74d73cad86bf81fdfee2bea3ef2d1/website_sale_subscription/views/templates.xml#L61 [4]: https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L130 [5]: https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/website_sale_subscription/static/src/js/variant_mixin.js#L18-L20 [6]: https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L138 opw-5380240 Forward-Port-Of: odoo/enterprise#103663 Forward-Port-Of: odoo/enterprise#102427
This update simplifies how AI errors are handled in live chat. Previously, a technical error message was translated for users, but a traceback still appeared. Now, errors are handled more gracefully, providing a generic message to users and allowing support teams to better understand the issue.
Original PR description
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function…
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms. The problem with this approach is two-fold. Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless. Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out. In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat. task-5177169 Forward-Port-Of: odoo/enterprise#97516
This update ensures that users who initiate document signing (requesters) can always access the finalized, signed documents. Previously, access rights weren't automatically set, preventing requesters from viewing the completed documents. The fix grants both the requester and signer 'view' access to the signed document.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#103470 Forward-Port-Of: odoo/enterprise#97132
This update resolves an issue where scrolling in the Gantt view would cause the interface to freeze. The fix ensures selections work smoothly, even with extensive scrolling, by adjusting how the system identifies selection targets and triggering necessary cleanup processes.
Original PR description
Previously, scrolling too far during a selection or multi-selection in the Gantt view caused the interface to appear "frozen". This was caused by 2 problems: - virtualization made the initial "dragged" cell (i.e. the cell on which the selection starts, which is the recognized drag target) disappear when scrolling too far, causing the drag sequence to be interrupted; - interrputing the selection drag sequences did not call the proper cleanup functions, leaving both selection "ghost" cells and badges visible. This commit fixes both of these issues: - drag target for selection is now the cell container (not affected by virtualization), and not the cells themselves; - cleanup functions related to selection and multi-selection are now called on "dragend" instead of the "drop" handler, allowing them to be applied everytime they're needed. Forward-Port-Of: odoo/enterprise#103694 Forward-Port-Of: odoo/enterprise#103499
This update improves the speed of the sales reconciliation feature by optimizing how sale order data is retrieved. Previously, all sales orders were loaded every time a partner's reconciliation was viewed. Now, the system efficiently fetches order counts initially, reducing the number of database operations and significantly speeding up the process for users.
Original PR description
Before this commit: We fetch all the sale orders for a partner every time we open unfold lines. This commit aims to reduce orm operations by fetching the sale orders counts one time upon loading the bank reconciliation for the first time or changing the pager. task-5241035 Forward-Port-Of: odoo/enterprise#100479
This update resolves an issue where the Salary Calculator view displayed blank fields when certain employees were selected. The fix ensures the correct salary calculations are performed by preventing unintended data loss during the simulation process. This improves the accuracy of payroll data.
Original PR description
This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set. Steps to Reproduce : First Change to either…
This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set. Steps to Reproduce : First Change to either the default company (MyCompany) or Demo Belgian company Payroll -> Employee -> Salary Calculator -> choose an employee. Bug : All fields in the Salary Calculator view are empty (evaluated as False). Root Cause : Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using: payslip.version_id.write(new_payslip_vals) Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False. Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation. This PR references this one odoo/enterprise#102371 Task - 5387155 Forward-Port-Of: odoo/enterprise#102884
This update resolves a critical issue preventing connections to IAP Codaclean, which was caused by a missing parameter. The team also streamlined the VAT calculation process by removing a computed field and implementing a direct method, improving efficiency. This ensures seamless integration with Codaclean for Belgian users.
Original PR description
Connections to IAP Codaclean are failing because of missing `enterprise_number` param. no-task-id Forward-Port-Of: odoo/enterprise#103724
This update resolves issues with accurately managing packages within the Barcode app, specifically related to internal transfers and packing operations. The changes ensure that packages are correctly assigned and tracked during processes like unpacking and transferring goods, improving overall inventory accuracy.
Original PR description
This PR fixes some issues with the packages in the Barcode app. See commit message for more details. [task-5116602](https://www.odoo.com/odoo/966/tasks/5116602) Forward-Port-Of: odoo/enterprise#94805