Tuesday, February 24, 2026
10 changes · saas-18.3
Resolved issues and error corrections
A recent update to the Hong Kong payroll salary rules required an update to the associated test suite. This change ensures that all tests accurately reflect the new rules, maintaining the integrity of the payroll calculations. This fix prevents potential discrepancies in reported payroll data.
Original PR description
In odoo/enterprise:100842 a salary rule was corrected, but the related tests were not. This will correct that mistake. Forward-Port-Of: odoo/enterprise#108241
This update resolves an issue where the payment QR code remained visible on the customer display after an order was completed. The fix clears relevant data when an order is finalized, ensuring the QR code automatically closes and improving the customer experience. This prevents unnecessary steps for the user.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249932 Forward-Port-Of: odoo/odoo#244991
This update fixes an issue where deactivated tax withholdings were still being calculated in vendor payments. The fix ensures that inactive tax settings are no longer included in payment calculations, improving accuracy and preventing incorrect financial reporting. This change was implemented by adding a filter to the tax retrieval function.
Original PR description
# How to reproduce - Install the l10n_ar_withholding module - Pick a Vendor and add a Purchase Withholding tax in the accounting tab - Go into configuration and disable that tax - Create a Vendor Bill with that Vendor - Confirm the bill and create a payment # The problem The deactivated tax is still computed in the payment # Why The function that fetches the withholding taxes does not check if the taxes are active or not # The fix I though of 2 solution : - Add an override to remove the taxes from the Vendor when they are deactivated - Add a filter to the fetch function to check if the taxes are active I chose the 2nd solution as it is the least invasive one. opw-5917257 Forward-Port-Of: odoo/odoo#247831
This update corrects a test case related to how Odoo handles multiple product transfers. The change ensures that transfers now correctly merge with existing ones only when a procurement group is specified, aligning with recent updates to the picking move merge behavior. This ensures accurate tracking of inventory movements.
Original PR description
Fix the test case to align with the updated picking move merge behavior, where the next transfer merges into an existing one only when a procurement group (group_id) is set TaskID-5242340 Forward-Port-Of: odoo/enterprise#99342
This update fixes an issue in the barcode picking interface where users were repeatedly prompted to confirm adding multiple extra products. Now, the confirmation dialog opens only once and dynamically updates with the selected extra products, streamlining the process and reducing user friction. This improves efficiency when picking multiple items using barcodes.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#107932 Forward-Port-Of: odoo/enterprise#104932
This update resolves an issue where the onboarding tour incorrectly targeted disabled calendar slots in the yearly calendar. The fix excludes ‘disabled’ weekday cells, ensuring the tour reliably identifies and clicks the first available Thursday, even when the calendar initially renders empty slots (e.g., for January 1st falling on a weekend).
Original PR description
Before, the tour attempted to click the “first Thursday” by selecting the first .fc-day-thu element in the DOM. The yearly calendar sometimes renders an initial “empty”/disabled weekday cell (when Jan 1 is Fri/Sat/Sun), so the first .fc-day-thu can be a disabled slot with no actionable element. That makes firstChild de-facto empty and the tour fails (seen reproducibly when the server date is set to years like 2027/2028, for example). Excluding .fc-day-disabled makes the selector target the first real Thursday cell task-5930501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248275
This update resolves a testing issue that prevented users from validating Arabic VAT invoices. The change uses elevated permissions (sudo) to write necessary files, ensuring the testing environment functions correctly regardless of user access rights. This improves the reliability of our Arabic VAT compliance testing.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update corrects a display issue in the Timesheet app's grid view. Previously, hovering over the total overtime cell showed 'Weekly Overtime' instead of the correct 'Total Overtime'. The fix renames the cell to 'Total Overtime' to accurately reflect overtime calculations across different time periods (day, week, month).
Original PR description
### Issue: When displaying the month in the grid view and hovering the bottom right cell, where the total overtime is displayed, it shows "Weekly overtime". ### Steps to reproduce: - Open Timesheet app - In "My Timesheet", display the grid in day or month - Hover the bottom right cell - It displays "Weekly Overtime" ### Solution: Rename it to "Total overtime" to handle all periods (day, week, month). opw-5502864 Forward-Port-Of: odoo/enterprise#107642
A bug was causing errors when setting up email approval rules in web_studio. This update corrects a technical issue related to how domain definitions were being handled, ensuring that approval rules with 'not set' operators now function correctly. This prevents errors and ensures proper email rule configuration.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#107558 Forward-Port-Of: odoo/enterprise#107432
This update fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice names are now correctly formatted in Spanish, as required by the Ecuadorian tax authority (SRI). This ensures accurate and compliant electronic invoicing.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914