Monday, December 15, 2025
18 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where applying discount codes would cause errors when a loyalty program was previously archived and then unarchived. The change ensures the system checks for duplicate discount codes, even when records are archived, preventing conflicting rules and ensuring smooth discount code application.
Original PR description
Currently, an error occurs when a user applies a discount code to the cart. Steps to reproduce: - Install the `website_sale_loyalty` module. - Go to `Discount & Loyalty` and create a new program with…
Currently, an error occurs when a user applies a discount code to the cart. Steps to reproduce: - Install the `website_sale_loyalty` module. - Go to `Discount & Loyalty` and create a new program with `Program Type = Discount Code`. - Under the `Rules & Rewards` tab, add a rule with a `code (e.g., demo)`. - `Archive` the program record. - Repeat `steps 2 and 3`. - `Unarchive` the first record. - Go to `Website` > `Shop`, add a product to the cart, and go to the cart page. - Apply the code `demo`. `ValueError: Expected singleton: loyalty.program(2, 3)` This error occurs when a user creates a sale loyalty program and adds a loyalty rule with a code, then archives that record. If the user creates the same record again and later unarchive the first record, there will be two rules with the same code, resulting in two loyalty programs [1], which raises the error [2]. This commit ensures that the system also checks archived records when unarchiving and verifies that there are no two or more programs with the same code being unarchived, so that no conflicting rules are activated. [1]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1351 [2]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1371 sentry-6871330244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239713 Forward-Port-Of: odoo/odoo#226801
This update fixes a confusing issue on the POS receipt where all tax columns (CGST, SGST, IGST) were displayed together. Now, the receipt correctly shows only the relevant tax column – either CGST+SGST or IGST – based on the transaction, ensuring accurate and clear reporting for Indian businesses.
Original PR description
Description of the issue/feature this PR addresses: - The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable. - This is incorrect because only CGST+SGST or IGST should be…
Description of the issue/feature this PR addresses: - The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable. - This is incorrect because only CGST+SGST or IGST should be displayed, not all three. Current behavior before PR: - The receipt always displays CGST, SGST, and IGST columns at the same time. <img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/5c8487c7-c497-4c82-ad80-8cf0e98fbf38" /> Desired behavior after PR is merged: - The receipt shows only the correct tax columns based on the transaction: - Shows CGST and SGST when GST applies. - Shows IGST when IGST applies. <img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/68d2fb58-9e15-4861-a71f-ccb2d978e544" /> Changes implemented in this commit: - Added `t-if="l10n_in_hsn_summary.has_gst"` to CGST and SGST headers. - Added the same condition to CGST and SGST values in the item rows. task-5268935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236243
This update removes messages indicating the POS system's certification status. Currently, the POS is only certified by the LNE in version 18.0, and this change ensures users don't see outdated information until a higher version with full certification is released. This simplifies the user experience and avoids potential confusion.
Original PR description
The POS in only certified by the LNE in version 18.0. Until such time that we receive the certification in a higher version, we will disable the certification status messages. task-5386904 Forward-Port-Of: odoo/enterprise#102028
This update resolves a problem where Odoo's IoT Box connections were failing due to a change in how response data was handled. The team adjusted the controller to correctly look for a key session ID in the websocket response, ensuring stable connections for IoT Box users. This prevents disruptions to critical data access.
Original PR description
In odoo/odoo#237586 we removed the `action_args` dict in the action response. As a result, websocket responses are ignored when using a stable IoT Box: the controller looked for `session_id` in `action_args`.
This update ensures that Odoo service restarts on IoT Boxes properly terminate all background threads. Previously, thread termination wasn't consistently handled, leading to potential issues. This change improves the stability and reliability of the Odoo service, particularly in environments like IoT Boxes.
Original PR description
To ensure all threads are killed when we restart the Odoo service on the IoT Box, we need to ensure they all have the `daemon=True`. Some already had the property set, but in the sub class attributes, so it was not properly taken into account. Task: 5410736
This update ensures that Luxembourg companies using the general ledger correctly generate FAIA XML reports. A recent requirement from FAIA (version 2.01) now mandates the inclusion of a 'PurchaseInvoices' tag, which this change adds to the report. This ensures accurate reporting for Luxembourg VAT compliance.
Original PR description
Since version 2.01 of FAIA, it is a requirement to include the `PurchaseInvoices` tag in the FAIA XML. With a `l10n_lu` company: - Create a vendor bill. - In the general ledger, download the FAIA XML report. In the generated XML document, the vendor bill will not appear under `PurchaseInvoices`. The `PurchaseInvoices` section is meant to mirror the `SalesInvoices` section and contains the exact same structure. This PR implements a generic template for both. **Specs and source** (in `FAIA_v2.01_full`): https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360572 Forward-Port-Of: odoo/enterprise#101958 Forward-Port-Of: odoo/enterprise#100697
This update resolves an issue where work orders were sometimes incorrectly marked due to a flaw in how their state was being evaluated. By adjusting the state check to occur at the 'button_mark_done' stage, the system now accurately reflects the correct work order status, ensuring data integrity for production planning.
Original PR description
Previous fix was not sufficient (https://github.com/odoo/odoo/pull/238832) In some cases, evaluating state and reservation_state within _post_inventory's override in mrp_account leads to incorrect workorders state. By evaluating them at end of button_mark_done, the workorders states are correct. task: 5247116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239839
This update resolves a minor visual glitch where the record selector's caret was causing unexpected changes in the input field's width. This ensures a consistent and properly sized user interface for selecting records, improving the overall user experience.
Original PR description
This commit fixes an issue where, when visible, the caret of the record selector component would take space and thus change the width of the input. Task: [5354466](https://www.odoo.com/odoo/project/133/tasks/5354466) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237054
This update resolves an issue preventing users from assigning analytic distributions to batch payments during bank reconciliation. The fix removes a restriction that was blocking edits to these payments, now allowing accurate tracking of financial data. This ensures validation errors are avoided and improves reconciliation processes.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131 Forward-Port-Of: odoo/enterprise#98874 Forward-Port-Of: odoo/enterprise#89858
This update improves the spreadsheet component by addressing several technical issues related to its performance and stability. Specifically, it fixes problems with conditional formatting previews, optimizes how dynamic dependencies are handled, and ensures style sheets are correctly delivered. This results in a more reliable and efficient spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5746fb19b [REL] 18.3.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5746fb19b [REL] 18.3.29 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f445897b4d [FIX] CorePlugins: Prevent dispatch during adaptRange [Task: 5380747](https://www.odoo.com/odoo/2328/tasks/5380747) https://github.com/odoo/o-spreadsheet/commit/6cbf13e091 [PERF] evaluation: cached dynamic dependencies [Task: 5407156](https://www.odoo.com/odoo/2328/tasks/5407156) https://github.com/odoo/o-spreadsheet/commit/5fe632cca0 [FIX] cf: conditional formatting preview is truncated for nothing [Task: 5344000](https://www.odoo.com/odoo/2328/tasks/5344000) https://github.com/odoo/o-spreadsheet/commit/a6c9f5c53a [FIX] Package: ensure we ship style sheets in releases [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/72daafed56 [FIX] figure: wrong focus change on figure unmount [Task: 5154025](https://www.odoo.com/odoo/2328/tasks/5154025) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where the system incorrectly processed vendor bills with a zero price in Italian e-invoicing XML. The fix ensures that the zero price is now correctly included in the XML, resolving a potential reporting discrepancy. This improves the accuracy of e-invoicing compliance for Italian businesses.
Original PR description
**Steps to reproduce:** * Install the **Italy – E-invoicing (l10n_it_edi)** module. * Create a product with a non-zero cost price. * Create a **vendor bill** for an Italian vendor using the **RC…
**Steps to reproduce:** * Install the **Italy – E-invoicing (l10n_it_edi)** module. * Create a product with a non-zero cost price. * Create a **vendor bill** for an Italian vendor using the **RC fiscal position**. * Add the product with **unit price = 0**, apply **RC tax**, and set the **Origin Document Type**. * Confirm the bill and click **Send to Tax Integration** to generate the XML in the chatter. * Upload the generated XML through **Accounting → Vendors → Bills → Upload**. **Observed behavior:** * The imported bill ignores the XML value **0.00** and uses the product's default price instead. **Cause:** * The XML’s `<PrezzoUnitario>` value is mandatory and may be **0**, but the code skipped it because `0.0` evaluates as falsy in the walrus assignment. **Fix:** * Always set the parsed `PrezzoUnitario` value (including **0.0**) on the invoice line. ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/PrezzoUnitario opw-5322187 Forward-Port-Of: odoo/odoo#239904 Forward-Port-Of: odoo/odoo#239419
This update ensures that group hierarchies are always displayed in the user's current language, regardless of language changes or new user creation. Previously, the system cached group hierarchy data in the default language, leading to inconsistencies. This fix improves the user experience by presenting accurate group information in the user's preferred language.
Original PR description
## Before this commit: When opening the user's form view, the group hierarchy is loaded using the context's language, and cached. However, switching language or creating a new user (which copies the portal template user) could result in the group hierarchy being displayed in the wrong language. This occurs because the cache does not account for the language changes. ## After this commit: Make the cache language-dependent to ensure group names and translated fields are always displayed in the user's current language. Also remove the unnecessary copy of the `view_group_hierarchy` field.
This update resolves a problem where users accessing branch companies couldn't see matching entries in the bank reconciliation process. The issue stemmed from a restriction in account access, preventing the system from retrieving necessary information. This fix ensures accurate reconciliation for branch company transactions.
Original PR description
**Steps to reproduce:** - Install Accounting - Create a branch company - Switch to the branch - Create a Bank journal for the branch - Create a Sales journal for the branch (You can duplicate the journals from the parent company) - Make sure that the accounts configured on the journals are linked the branch - Grant only access to the branch to a user - Connect with that user - Create an invoice - In the bank journal, create a statement line matching the amount of the invoice - Select the statement line **Issue:** In the "Matching Existing Entries" tab, there is no entry. **Cause:** When retrieving the accounts required for the domain to fetch these entries, no account can be retrieved because the user doesn't have access to the parent company. opw-5181909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239281
This update fixes a bug where import errors weren't shown during batch processing. Now, when an import fails due to incorrect data (like a missing value), users will receive a clear notification, ensuring data integrity and preventing silent import issues. This improves the reliability of the contact import process.
Original PR description
Steps to reproduce ================== - Go to contact, - Import the following file ```csv id,name,active __import__.res_partner_SV_test_01,Name 1,TRUE __import__.res_partner_SV_test_02,Name 2,TRUE __import__.res_partner_SV_test_03,Name 3,TRUE __import__.res_partner_SV_test_04,Name 4,TRUE __import__.res_partner_SV_test_05,Name 5,incorrect value __import__.res_partner_SV_test_06,Name 6,TRUE __import__.res_partner_SV_test_07,Name 7,TRUE __import__.res_partner_SV_test_08,Name 8,TRUE ``` - Set the batch size to 4 - Click on the import button => Only 4 records have been imported and no error is displayed Cause of the issue ================== Errors were only checked in test mode opw-5242285 Forward-Port-Of: odoo/odoo#239632 Forward-Port-Of: odoo/odoo#239109
This update fixes an issue where the VAT summary report in the Argentinian localization incorrectly calculated totals when invoices included both VAT (price included) and multiple IIBB taxes. The fix ensures that VAT amounts are counted accurately, matching the totals displayed in the accounting form, preventing inflated totals.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#98933 Forward-Port-Of: odoo/enterprise#85873
This update fixes an issue where public holidays were incorrectly added to leave duration calculations after a leave was confirmed. The fix recomputes the leave duration before confirmation, ensuring accurate tracking of leave time, especially when public holidays overlap with allocations. This prevents users from being incorrectly flagged for exceeding their leave balances.
Original PR description
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to…
### Steps to reproduce: - Install Time off apps - Create two consecutive allocations (e.g. one for 2025 and one for 2026) - Create a leave that overlap with the two allocation (e.g. from 8th Dec to 3rd Jan) - Create a public holiday at the beginning of the second allocation (e.g. on 1st Jan 2026) ### Cause: When we are checking the leave duration after having a public holiday the will return the attendance without the public holidays duration so when subtracting the attendance duration from the leave duration we will have a remaining amout equals to the public holiday duration and it will be considered as excess days. https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L228-L230 https://github.com/odoo/odoo/blob/06e47d8601ba56b1650eeaeef71ebd7a4af39b8b/addons/hr_holidays/models/hr_employee_base.py#L246-L254 ### Fix: We compute the leave duration before confirming it instead of computed them after opw-5006119 Forward-Port-Of: odoo/odoo#239926 Forward-Port-Of: odoo/odoo#235575
This update fixes an issue where loyalty discounts weren't correctly applying quantity-based discounts, leading to inaccurate calculations and potential discount limits. The change ensures that discounts are calculated proportionally to the quantity of each item purchased, resulting in more accurate and reliable loyalty program discounts.
Original PR description
Discounts based on the cheapest line were not accounting for the quantity on the line and this was causing issues with the computations when using a maximum discount amount. Changing the discountable value to be a ratio of the quantity on the line allows the cheapest product to be discounted at the correct amount without messing with the discount factor. opw-4998557 Forward-Port-Of: odoo/odoo#239349 Forward-Port-Of: odoo/odoo#222564
This update fixes an issue where the XML reports for Belgian accounting were incorrectly including a slash ('/') when there was no comment in the comment section. This change ensures the reports are properly formatted and compatible with accounting systems. It's a minor adjustment to improve report accuracy.
Original PR description
Since 17.0, we added a / when there was no comment in the comment section of the xml. This is wrong and should be left empty. opw-5242381 Forward-Port-Of: odoo/enterprise#101339 Forward-Port-Of: odoo/enterprise#100033