Tuesday, February 17, 2026
16 changes · saas-18.3
Resolved issues and error corrections
This update enhances accounting reports by allowing users to filter data across multiple journals simultaneously. Previously, filtering was limited to a single journal. This change provides greater flexibility and control for users analyzing financial data.
Original PR description
In accounting reports, we want to be able to filter on multiples journals if needed. This filter will allow us to do this. Using `context['search_default_journal_id'] = journal_ids` doesn't work as only the first id is passed to the filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247731
A recurring timeout issue during automated testing of the l10n_ke_edi_oscu_pos module was identified. This issue occurred when the system refreshed the page after adding products to the cart, triggering a database transaction. This PR increases the timeout duration and adds debugging information to address the problem.
Original PR description
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a…
There is an issue that seems to only happen on l10n_ke runbot that times out on tests that try to add a product to the cart in pos and then refresh the page. The l10n_ke_edi_oscu_pos module has a listener added on the order component which tries to automatically add the taxes to the products in the order. This triggers a transaction on indexed db. Since the tour test executes the refresh immediately after adding the product to the cart, it causes a timeout. I could not reproduce the issue locally, but it's been happening consistently on almost every nightly run, always on the l10n_ke run. This PR will increase the timeout and add some extra info to the timeout message to help with debugging in the future. Runbot error: [233525](https://runbot.odoo.com/odoo/runbot.build.error/233525) Task: [5897379](https://www.odoo.com/odoo/project/1737/tasks/5897379) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248257
This update resolves an issue where the 'Contact Us' button on product pages wasn't correctly redirecting users to snippets created through drag-and-drop. The fix ensures that anchors in the button URL are properly handled, allowing for seamless redirection to the intended snippets, particularly when dealing with zero-priced products.
Original PR description
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work…
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor. for ex: `#snippet-anchor` in the `Button URL` field in the settings. Cause: -------- This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place. Solution: ------------ To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on. This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside. Steps to reproduce: ----------------------- 1. Create a db in version 18.3 with website_sale installed. 2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings. 3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button. 4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings. 5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet. Ref PR: ---------- https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399 Attachments: ----------------- **Before Fix:** [vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0) **After Fix**: [vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5) - OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test report for MRP was failing because the administrator user lacked the necessary permissions to select product variants. This update adds the required user rights, allowing the test to pass and ensuring accurate reporting of product variants within the system. This resolves a critical issue impacting test report accuracy.
Original PR description
The _/mrp:TestReportBom.test_mrp_report_bom_variant_selection_ test was failling because administrator user couldn't use the product variants. The needed dropdown menu to switch variant wasn't displayed and the test failed. We add the "product.group_product_variant" rights to the user. Runbot error: 238917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where customers could still redeem expired ewallet points. The change prevents users from claiming points after their expiration date, ensuring accurate point balances and a better customer experience. This resolves an issue reported in opw-5476686.
Original PR description
### Issue: Due to this issue, ewallet points are claimable after expiry. #### Steps to reproduce: 1- Create a ewallet program, and generate an ewallet for a partner. 2- Set the expiration date in the past. 3- Create a SO with the same partner. 4- Click on reward. Expected: The ewallet shouldn't be claimable. Current outcome: The ewallet is claimable. opw-5476686 Forward-Port-Of: odoo/odoo#248528 Forward-Port-Of: odoo/odoo#247740
This update prevents an infinite page reload cycle when applying multiple gift cards from the same program. The fix addresses a discrepancy in how discount lines are handled, specifically related to multi-gift card applications. This ensures a smoother checkout experience for customers using gift cards.
Original PR description
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add…
### Issue: Applying multi gift card from the same program results in an infinite reload cycle. #### Steps to reproduce: 1- Create a gift card program and generate two gift cards. 2- In eCommerce add a deliverable product to cart. 3- Open cart and add both gift card codes. 4- Click on checkout to navigate to delivery step. The page is going to keep refreshing. ### Cause: The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.: https://github.com/odoo/odoo/blob/7462ec423e8b106a5175a71ac009176d16cdf225/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24 After the fix #191132, discount lines are grouped by `reward_id`. This is done because in the back-end, by applying a single percent discount, separate lines are created per product lines with different taxes, while in front-end there is still single line. However, that fix doesn't consider that a SO might have multiple lines of the same reward: ewallet, gift_card ### Fix: This can be fixed by separating logic of groupable lines which are the lines with `percent` mode, with `per-point` mode lines. Discount is the only mode that might be added to multiple lines separately, keeping #191132 fix, and `per-point` is the only mode that might be applied multiple times per reward (in ewallet and gift_card). opw-5485912 Forward-Port-Of: odoo/odoo#248215
This update fixes an issue where the table editor lost focus after deleting rows or columns, disrupting the editing workflow and causing confusion. Now, the editor automatically refocuses, ensuring a smoother and more intuitive experience when modifying table data.
Original PR description
**Current behavior before PR:** When a user deletes a row or column from table menu, the editor loses focus. As a result, actions like Undo do not behave as expected and require multiple attempts to restore the original table state. This breaks the editing flow, causes confusion when performing table-related actions. **Desired behavior after PR:** This PR ensures that editable is focused after deleting row or column from table menu. This commit also makes sure that selection is set properly and hint is visible on empty cell after deleting the column. task-5725593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248496 Forward-Port-Of: odoo/odoo#245433
This update resolves an issue where attendance managers couldn't edit their team members' records. The change ensures both managers and officers can now modify attendance data, improving workflow efficiency. Thorough testing has been added to ensure this fix is reliable.
Original PR description
The commit https://github.com/odoo/odoo/commit/d115cca1296c0bd20a2875bdaadf2a9136c33dda introduced the opportunity for attendance managers to edit their subordinates attendances, but the condition was lacking parenthesis, leading to an unexpected behaviour. This commit changes the condition so that it is possible both for a manager and an officer to do the edition. It also rewrite the tests in order to be more thorough. No related task Forward-Port-Of: odoo/odoo#248580 Forward-Port-Of: odoo/odoo#248471
This update fixes an issue where the system incorrectly treated re-deliveries as returns, leading to a single shipping label being generated. Now, when returning multiple packages, the system accurately processes all incoming shipments as returns, ensuring correct label generation and tracking.
Original PR description
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery -…
Issue ----- When doing delivery -> return -> re-delivery, only one label is received even when there are mutliple packages to be "re-delivered". Steps to reproduce ----- - Create a UPS delivery - Multiple packages - Validate transfer - Return - Validate IN - Return again - Add the UPS under the "additional info" tab - Ensure still multiple packages - Validate OUT Cause ----- When preparing the shipping data, we go through https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/delivery_ups_rest/models/delivery_ups.py#L120-L121 which leads us to do https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/delivery_carrier.py#L142-L155 so we end up with a single package to send to the delivery service. The reason `is_return_picking` is true is because the compute method only checks for an existing move with an `origin_returned_move_id`. https://github.com/odoo/odoo/blob/89733b0e4d1e9a57dd25f552db4e6330a6b14cdf/addons/stock_delivery/models/stock_picking.py#L53-L58 From a delivery flow perspective, it doesn't make much sense to consider outgoing shipments as returns. ----- Ticket: opw-5866100 Forward-Port-Of: odoo/odoo#246946
A recent issue with a specific POS printer (POS80D) was causing Odoo to crash. This pull request fixes a technical error related to USB communication, preventing the crash and ensuring reliable printer functionality. This resolves a reported problem impacting printer connectivity.
Original PR description
Seen on https://laloux-j.odoo.com/ 12/2 with a POS80D printer the printer triggers a core.USBError. This PR catches the corresponding exception 2026-02-12 04:21:12,496 1117 ERROR ? odoo.addons.iot_drivers.exception_logger: usb.core.USBError: [Errno None] Invalid descriptor task-5932720
This update corrects a bug preventing loyalty rewards from applying correctly when products are purchased in non-unit quantities (e.g., dozens). The fix ensures that rewards are accurately calculated based on the actual quantity purchased, regardless of the unit of measure. This improves the accuracy of loyalty program discounts.
Original PR description
### Issue: Due to this issue, applying a different uom than unit one, will not apply the reward regarding to quantities. #### Steps to reproduce: 1- Create a program: buy 12 get 6 free. 2- Create a SO, add a dozen of product to SOL. 3- Click on reward. Expect: 6 free unit is added. Current outcome: Nothing is added. Unless you add 12 dozens which is going to add 6 units. ### Cause: In checking rules, `product_uom_qty` is directly used without conversion to quantity. Note: `test_different_uom_to_hours_on_sale_order_confirmation` is failing due to this fix, because the uom_id unit/dozens and hours/days are not compatible. As this is not possible in UI, IMO we can delete the breaking SOL in that test. opw-5913638 Forward-Port-Of: odoo/odoo#248527 Forward-Port-Of: odoo/odoo#247743
This update resolves an issue where the journal filter selected in the general ledger report wasn't carried over when viewing journal items. Now, when you select a journal in the report, the 'Journal Items' view correctly displays both the related invoices and the corresponding journal entry, providing a more complete financial overview.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry. Forward-Port-Of: odoo/enterprise#106836
This update fixes a reporting issue where VAT numbers were incorrectly excluded from INF reports for Estonian businesses. Now, the reports include partners without VAT numbers, and a clearer warning is displayed when VAT information is missing, ensuring more accurate financial reporting. This improves compliance and data reliability.
Original PR description
Both inf-a and inf-b reports should include partners with no vat number. Also updated partner warning on reports to harmonize with main query itself. Now warning is shown if: - no country and no VAT - no country and VAT not starting with EE - no country and VAT is "/" Forward-Port-Of: odoo/enterprise#106954
This update clarifies the visibility of country-specific fields within the Belgian payroll and fleet modules. Previously, generic fields were moved to a common module, but this change now ensures that the unique Belgian fiscal logic remains contained within the dedicated Belgian module. This maintains the correct functionality for Belgian businesses.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656 Forward-Port-Of: odoo/enterprise#106456
This update resolves an issue where Fedex freight delivery requests were failing due to missing information required by the Fedex API. The fix adds a necessary field, 'expressFreightDetail', to the API request, allowing delivery rates to be retrieved and validated. This ensures users can accurately process Fedex shipments.
Original PR description
Issue ----- Fedex freights services require extra information not present in the db, so requests will not be accepted by the API. A rate can be retrieved but the delivery cannot by validated by users as they get a `SHIPMENT.LOADCOUNT.INVALID` error. This is due to the lack of a `expressFreightDetail` entry in the request sent to the Fedex API. This `expressFreightDetail` field should contain some information which Odoo does not have a way to retrieve, such as a `bookingConfirmationNumber`. API details: https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html#:~:text=expressFreightDetail Feedback 5913471 ----- Ticket: opw-5876616 Forward-Port-Of: odoo/enterprise#106590
This update ensures that all rates displayed on the printed payslip are formatted to a maximum of 4 decimal places. This improves the clarity and consistency of the payslip output, aligning with reporting requirements. The change was implemented to address a formatting issue.
Original PR description
This commit improves the payslip display by limiting all rates to 4 decimals max on the printed pdf payslip. Task: 5709739 Forward-Port-Of: odoo/enterprise#104915