Daily updates from Odoo
Navigate
Branch
Monday, December 15, 2025
143 changes
19 changes
New functionality added to Odoo
This update adds a crucial link to documentation for Pinelabs payment terminals within the Odoo Point of Sale settings. This ensures that users can easily find the information they need to properly configure and utilize Pinelabs payment processing, improving operational efficiency and reducing potential support requests.
Original PR description
In this commit: =============== - We have added a missing documentation link in the settings for the Pinelabs payment terminals. Task: 5407021
Enhancements to existing features
This update restricts access to version forms within the HR module, ensuring that only HR users and managers can view them. Previously, all users could access these forms, and this change enhances security and streamlines workflows by limiting access based on user roles.
Original PR description
*= hr_payroll, hr_contract_salary Purpose of this PR: - Make version quick access open employee form with selected version if the user has access. - Only HR users/managers can access version form, others can not see quick access. This PR includes: - Added new helper action on hr.version to open the employee form. - Override get_formview_action in payslip and offer models to redirect quick access to employee form with selected version. - Adjusted view fields to restrict version access: - Users with access can open the version from quick access. - Others can see it without the quick access (using no_open option). task-4963805
This update restricts access to employee version quick access based on user roles. HR managers and employees can now directly access the employee version form, while other users will continue to see the standard view. This enhances security and streamlines workflows for HR personnel.
Original PR description
*= hr_payroll Purpose of this PR: - Make version quick access open employee form with selected version if the user has access. - Only HR users/managers can access version form, others can not see quick access. This PR includes: - Added new helper action on hr.version to open the employee form. - Override get_formview_action in payslip and offer models to redirect quick access to employee form with selected version. - Adjusted view fields to restrict version access: - Users with access can open the version from quick access. - Others can see it without the quick access (using no_open option). task-4963805
This update enhances the Point of Sale system by automatically saving log messages to the user's browser for 24 hours. This allows our support team to quickly diagnose and resolve issues by providing clients with easy access to these logs. A download button has been added to simplify the process of sharing these logs with our support team.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/100183 This commit extends the `logPosMessage` function in the POS to also save each log message to a `Logger` instance (which persists the logs for 24 hours in the browser storage). A download button is added to download these logs, which the client could then send on to the support team. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236927
This update adds logging to the blackbox communication process, which helps our clients troubleshoot issues more effectively. Combined with a related change to save and download logs, this enhances our ability to diagnose and resolve problems quickly. This improves client support and reduces downtime.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236927 This commit adds several log messages for the communication with the blackbox. In combination with the associated Community PR to save and download these logs, this should enable easier debugging when clients experience problems. Forward-Port-Of: odoo/enterprise#100183
Resolved issues and error corrections
This update resolves an issue where applying discount codes would cause errors when a loyalty program was archived and then unarchived. The fix 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 an issue where subscription products weren't displaying prices with tax, even when the website setting was enabled for tax-inclusive pricing. The change ensures that the correct company ID is used to determine tax applicability, resulting in accurate tax-inclusive prices for subscriptions.
Original PR description
subscriptions Despite enabling the website setting to display tax-inclusive prices, subscription products show prices without tax when a recurring pricelist is configured. In `_get_sales_prices`, the product’s company ID is compared to the website’s company, but products visible to all have a false company ID, and products assigned to a parent company retain the parent’s company ID. As a result, when the product’s company ID does not match the website’s company ID, no taxes are applied.Instead, _filter_taxes_by_company should be used to determine whether the company can access the product’s tax_id. opw-5222411
This update resolves a potential error that occurred when creating invoices with zero amounts in a different currency (CL). The fix prevents a division-by-zero error during currency calculations, ensuring invoices can be confirmed reliably. This improves the stability of the CL accounting module.
Original PR description
Steps to reproduce:
--------------------
1. Install l10n_cl and switch to the CL company
2. Create a new invoice:
- Change the currency to a value different from the company currency
(e.g., from CLP to USD)
- Add an invoice line with a price value of 0
- Remove the default tax value
3. Try to confirm the invoice
Issue:
------
A traceback occurs:
`ZeroDivisionError: float division by zero`
Cause:
------
Since the price value is 0, the `amount_total` of the move becomes 0.
When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError.
Solution:
---------
Add a conditional check before division to ensure the `amount_total` is non-zero
Related enterprise PR: https://github.com/odoo/enterprise/pull/99518
opw-5247058
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239247
Forward-Port-Of: odoo/odoo#235252This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before calculations, preventing a division-by-zero error and improving invoice processing stability. This ensures invoices can be correctly processed, particularly when dealing with different currencies.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101695 Forward-Port-Of: odoo/enterprise#99518
This update fixes a confusing issue on the POS receipt in India 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, improving clarity for users and ensuring accurate reporting.
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 corrects a recent change during the forward port process. The automatic recalculation of the 'checked' status for bank statements was unintentionally removed. Reintroducing this functionality ensures accurate tracking of statement processing and prevents potential discrepancies in financial reporting.
Original PR description
During the forward port of: https://github.com/odoo/enterprise/pull/94552 the recompute of the checked field was removed. It needs to be added back no task id
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 certified version 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 corrects a bug in the l10n_es_edi_tbai module that prevented the correct 'FechaOperacion' field from being generated in TBAI XML invoices when the invoice date and delivery date were set to a past date. This ensures compliance with Spanish tax regulations and accurate invoice generation.
Original PR description
With l10n_es_tbai: - Create an invoice with an `invoice_date` and `delivery_date` that are the same and earlier than today. - In the generated TBAI XML, `FechaOperacion` is missing. In the TBAI XML, `FechaExpedicionFactura` corresponds to the date on which the XML is generated. `FechaOperacion` corresponds to the `delivery_date` and should appear whenever it differs from the issue date. The TicketBAI specs define `FechaOperacion` as: > “Date on which the transaction was carried out, whenever it differs from the issue date.” So when the invoice date and delivery date are equal but set in the past, `FechaOperacion` is not generated, even though it should be. opw-4477135 opw-4477135 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239189
This update resolves a technical issue preventing stable IoT Box users from receiving correct websocket responses. A recent change removed a key data element, causing the controller to incorrectly search for session IDs. This fix ensures proper websocket communication for our IoT Box deployments.
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`. Forward-Port-Of: odoo/enterprise#102044
This update resolves an issue where users didn't receive notifications when attempting to create timesheets for weekend shifts in calendar mode. The fix ensures that a notification is displayed when a shift isn't created, improving the user experience and preventing missed time tracking. This ensures accurate time reporting.
Original PR description
Steps to reproduce: - Open Timesheets and navigate to calendar mode (My Timesheets). - Click on weekend cell and no shift is created and no notification or explanation is given Issue: - No issue explanation why timesheets were not created. Fix: - Check if we have skipped creating record because we have no timesheets and raise the notification accordingly task-5076642
This update fixes an issue where scanning a lot in a batch transfer would incorrectly update a different line instead of the intended one. Previously, the system prioritized completed lines, leading to inaccurate inventory tracking. This change ensures that scanning a lot updates the correct line, maintaining accurate stock levels.
Original PR description
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create…
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create a storable product tracked by lots and put 10 x lot1 in stock - Create and confirm a delivery for 10 units - Create a batch transfer with your delivery - Process your transfer from the barcode app - Scan one unit of LOT1 and put in pack - Toggle sublines select the 0/9 subline without lots nor package - Scan LOT1 #### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9 ### Cause of the issue: Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot. opw-5340865 Forward-Port-Of: odoo/enterprise#101908 Forward-Port-Of: odoo/enterprise#101611
This update fixes a bug where credit notes weren't properly accounted for when settling invoices. The change ensures credit notes are now correctly processed, allowing them to reduce the total amount settled. This improves the accuracy of financial reporting and reconciliation.
Original PR description
We had a bug when settling invoices and credit notes of a customer. The credit notes where not correctly computed. Steps to reproduce: ------------------- In accounting: * Create and confirm a customer invoice for a total of 10$. * Create and confirm for the same customer a credit note for a total of 2$. In POS: * In a seesion, open the customer selection menu. * In the burger menu at the right of our customer, select Settle invioces. * Select our invoice and credit note. > Observation: The credit note was previously seen as an amount to pay. Why the fix: ------------ Recomputing updates existing credit notes to use the signed residual logic. The domain change allows credit notes with negative pos_amount_unsettled to appear. After these changes, credit notes should appear in the "Settle invoices" dialog with negative amounts, and selecting them will create negative lines that reduce the total. opw-5257884 Forward-Port-Of: odoo/enterprise#101186
This update fixes a calculation error in the MRR evolution dashboard that was causing 'Contraction' figures to be double-counted. The change ensures the dashboard accurately reflects MRR trends by properly incorporating contraction data, which was previously included in the 'Up/Downgrade' calculation. This improves the accuracy of the dashboard's reporting.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#101598 Forward-Port-Of: odoo/enterprise#96878
This update fixes issues where changes to nested card images were incorrectly applied to other cards, or where cards without cover images incorrectly displayed cover image options. The fix ensures that image settings are applied only to the specific card being edited, improving the user experience and consistency.
Original PR description
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image…
This commit fixes three issues occurring when editing nested `s_card` snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover image option if it contained a child `s_card` with a cover image. Cause: The `querySelector` in `CardImageOption` could detect images inside child snippets. Fix: Now the `querySelector` only searches among direct children of the snippet root element. **Problem 2 - Ratio settings applied to all child cards** Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested cards. Cause: The `we-select` in `s_card` options targeted `.o_card_img_wrapper`, causing the class to apply to all descendants. Fix: The selector is now `>.o_card_img_wrapper`, so the option acts only on the current snippet. **Problem 3 - Parent image positioning leaking to children** Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images. Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements matching `.o_card_img_wrapper`. Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`. task-5349540 Forward-Port-Of: odoo/odoo#239503 Forward-Port-Of: odoo/odoo#237587
11 changes
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
3 changes
Resolved issues and error corrections
This update fixes an issue where rental price calculations were inconsistent due to how relativedelta handled time-zoned dates. The change ensures accurate price calculations by correctly accounting for time zone differences, preventing discrepancies in rental durations. This improves the reliability of rental pricing displayed to customers.
Original PR description
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work…
Relativedelta on UTC dates or time-zoned dates doesn't return the same result. In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates. Example: Consider a website in UTC+1 (Brussels timezone DST off). And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). Converted in UTC for the back-end, we have: from the 30/11/2025 23h00 to the 31/12/2025 22h59. relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow: 30/11/2025 23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. Time difference = 1 month, 23 hours, 59 minutes. Price = 2 months. Consider a second rental from the 01/01/2026 to the 31/01/2026. 31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. Time difference = 30 days, 23 hours, 59 minutes. Price = 1 month. opw-5130762 Forward-Port-Of: odoo/enterprise#98571
This update resolves an issue where users couldn't adjust prices within the POS system when utilizing the Swedish blackbox integration. Now, price control is enabled, aligning with the requirements for the Swedish blackbox, unlike the Belgian version where it was previously mandatory. This ensures accurate pricing for Swedish POS transactions.
Original PR description
Before this commit, user couldn't control the price in the POS if using the swedish blackbox. After this commit, user can control the price. It's not clear why the behavior at integration was set to this but it appears that it's not mandatory for swedish blackbox unlike the belgian one. opw-5253401 Forward-Port-Of: odoo/enterprise#100984
This update corrects an issue where subscription products incorrectly displayed both recurring and list prices on their product cards. Now, subscription products show only the recurring price, ensuring accurate pricing information for our customers. This improves clarity and simplifies product selection.
Original PR description
Version - 18.0 Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products → Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip…
Version
- 18.0
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products → Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
* "Based on order" showed end of the period.
* "Based on delivered" showed beginning of the period.
Issue 2: Product card shows both recurring and sales price
1. Go to Products → Products in subscription app.
2. Observe that the product card displays both recurring price and sales price
After this PR:
- Tooltip now correctly states:
* for "based on order" invoice_policy -> beginning of period
* for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.
task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />
Forward-Port-Of: odoo/enterprise#9501023 changes
New functionality added to Odoo
This update improves the composer experience by automatically displaying a date picker when a date is specified. This allows users to easily select and confirm dates within the composer, reducing errors and streamlining the process. It's a small but helpful enhancement for data entry.
Original PR description
When opening a composer whose content is a date literal, a date picker is now displayed to help selecting a date. Task: [4873953](https://www.odoo.com/web#id=4873953&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update enhances the new user onboarding process by adding information about the 'Create To-Do by Email' feature. It includes a clear explanation and a clickable email alias, making it easier for new users to quickly create tasks via email. This streamlines the initial setup and improves user productivity.
Original PR description
This commit adds a new section to the user's onboarding welcome to-do. This section explains the "Create To-Do by Email" feature and provides the clickable email alias to create todo. task-4781859
Enhancements to existing features
This update enhances the Odoo Enterprise system by making all relevant benefits fields visible for hourly wage contracts. This change ensures that all necessary information is easily accessible, improving clarity and streamlining the management of hourly employee benefits. The update corrects a previous limitation in the system.
Original PR description
The purpose of this update is to ensure that all relevant fields are visible for hourly wage contracts, improving clarity and ensuring all necessary information is easily accessible. This PR includes the following changes: - Made all relevant benefits fields visible for hourly wage contracts, similar to fixed wage contracts. - Removed ir.ui.view from hr_contract_salary_payroll to make some fields visible for hourly wage. - Updated the visibility logic for contract fields to ensure they are displayed appropriately for hourly wage contracts. Task - 4421240
This update corrects a calculation error in employee EPF contributions. As of October 2025, a new flat rate schedule is being implemented. This change ensures accurate EPF calculations based on the correct flat rate, preventing discrepancies in payroll processing.
Original PR description
Previous behavior applies a dynamic rate on employee's salary rather than using the flat rate schedule. As of Oct 2025 there is a flat rate schedule to follow for computing the EPF contributions. For example for a wage of 6250, a 12% rate would be 750 (which is now incorrect) and according to the flat rate schedule is 756. task-5286179
This update aligns the dialogs used in Odoo's web Gantt and Studio modules with recent community changes. This ensures consistency and a more modern user experience for these key business tools. The changes are primarily focused on improving the visual presentation and functionality of the dialogs.
Original PR description
This PR adapts dialogs by mirroring community changes. Requires: - https://github.com/odoo/odoo/pull/238855 task-5159944
This update enables users to export multiple BR invoices as XML files in a single batch, streamlining the process for generating required reports. Previously, users could only export invoices individually. Additionally, the system now intelligently handles errors during export, excluding problematic invoices from the batch without disrupting the entire process.
Original PR description
Add a new button in account.move list view for BR companies, allowing the user to export xml files of multiple moves in batch. If any selected moves is not valid, raise a RedirectError to open a list view with all problematics moves. Linked:https://github.com/odoo/odoo/pull/235532 task-5105859
Resolved issues and error corrections
This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before currency calculations, preventing a division-by-zero error and ensuring smooth invoice processing. This improves the stability of the CL invoicing process.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101695 Forward-Port-Of: odoo/enterprise#99518
This update fixes an issue where global discounts on online orders weren't correctly calculating taxes. Now, discounts accurately reflect tax amounts based on the order line, aligning with standard Point of Sale and Sales tax calculations. This ensures accurate tax reporting and pricing for global discount orders.
Original PR description
Before this commit: --- - When an online order with an order-level (global) discount was placed, the discount line did not properly include tax calculations. After this commit: --- - Global discounts now compute taxes based on the order line taxes. - The discount line includes accurate tax details. - Uses the same standard tax computation flow as in Point of Sale and Sales. task-5047965 Forward-Port-Of: odoo/enterprise#96981
This update corrects misleading tooltip text on product forms related to subscription invoices and ensures that product cards display only the recurring price for subscription products. This improves clarity and accuracy for users managing subscription orders, aligning with the expected presentation of recurring charges.
Original PR description
Steps to Reproduce: Issue 1: Incorrect tooltip text 1. Go to Products -> Products in subscription app. 2. Open a product page and select goods product type 3. observe product_tooltip show incorrect…
Steps to Reproduce:
Issue 1: Incorrect tooltip text
1. Go to Products -> Products in subscription app.
2. Open a product page and select goods product type
3. observe product_tooltip show incorrect wording:
- "Based on order" showed "end of the period."
- "Based on delivered" showed "beginning of the period."
Issue 2: Product card shows both recurring and sales price
1. Go to Products -> Products in subscription app.
2. Observe that the product card displays both recurring price and list price
Solution:
- Remove `product_template_form_view` from `sale_subscription_stock` and move
it to `sale_subscription`, as the tooltip logic now applies to both goods and
service-type products.
- In subscription product display only recurring price
task-5156390
---
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/487fa076-264d-4565-a048-343c7317db42" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/d4fc4543-c7f4-4a98-be8f-b898057de896" />This update addresses a situation where the POS system was incorrectly displaying certification status due to its current version (18.0) being uncertified by the LNE. Until a higher certified version is available, the system will now automatically hide these certification messages to avoid misleading users. This ensures a cleaner and more accurate user experience.
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 commit corrects a recent pricing error affecting products with multiple plans and variants. The previous changes removed crucial logic, leading to incorrect price calculations. Reverting the changes restores the accurate price computation for these products, ensuring correct sales pricing.
Original PR description
This commit reverts the modifications introduced in the one-time sale [PR](https://github.com/odoo/enterprise/pull/77981). Those changes caused incorrect pricing behavior for products with variants, as the necessary logic for handling multiple plans and variants was removed. By reverting, we restore the correct price computation for products that have both multiple plans and variants. opw-5224319 Forward-Port-Of: odoo/enterprise#100654 Forward-Port-Of: odoo/enterprise#93463
This update resolves an issue where by-products weren't correctly registered during multi-step manufacturing processes. The fix ensures that by-product lines are created with the correct pre-production and production locations, streamlining the manufacturing workflow. This issue is now resolved in version 18.0 and later.
Original PR description
### Steps to reproduce: - In the settings enable By-Products an Multi-step routes - Put your warehouse in manufacturing in 3 steps - Create two storable products: - Final Product (FP) with an empty…
### Steps to reproduce:
- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
- Final Product (FP) with an empty bom
- By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination
### Cause of the issue:
Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.
### Note:
The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f
opw-5350222
Forward-Port-Of: odoo/enterprise#101861
Forward-Port-Of: odoo/enterprise#101087A recent test was failing due to timing issues when switching users and updating shop floor records. This fix introduces a two-step process, first verifying the user switch and then confirming the presence of the expected records, ensuring the test's reliability.
Original PR description
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps:…
The test `test_shop_floor_my_wo_filter_with_pin_user` sometimes fails on these steps: https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L177-L190 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L196-L206 https://github.com/odoo/enterprise/blob/422ac3d5b10c44233321010b9ecb8e37735b3ea3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L212-L221 This happends since changing the user requires some time to display the related shopfloor records, but the steps check the number of visible records as soon as it has switched rather than when it is sure that the records are displayed. #### Fix: Since switching employees will first empty the recordset and later display the related records, we can split the steps in two. We first check that we switched users, then we check the existence of a record that is not present for the previous user, and only then perform the related checks. #### runbot-226734 Forward-Port-Of: odoo/enterprise#101602 Forward-Port-Of: odoo/enterprise#100746
This update fixes an issue where scanning a lot in a batch transfer incorrectly updated line quantities. Specifically, when a subline without a lot was scanned after a related line was completed, the quantity was miscalculated. This change ensures that lotless lines are correctly updated during barcode scanning, improving inventory accuracy.
Original PR description
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create…
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create a storable product tracked by lots and put 10 x lot1 in stock - Create and confirm a delivery for 10 units - Create a batch transfer with your delivery - Process your transfer from the barcode app - Scan one unit of LOT1 and put in pack - Toggle sublines select the 0/9 subline without lots nor package - Scan LOT1 #### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9 ### Cause of the issue: Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot. opw-5340865 Forward-Port-Of: odoo/enterprise#101908 Forward-Port-Of: odoo/enterprise#101611
This update resolves an issue where the OCR process incorrectly assigned foreign currencies (like Convertible Marks) to expense items linked to products with standard prices. Now, users can correct the currency and total amount after the OCR, ensuring accurate reimbursements and preventing disruptions to the expense workflow. This fix improves the reliability of expense data.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236 Forward-Port-Of: odoo/enterprise#101822 Forward-Port-Of: odoo/enterprise#89093
This update corrects a visual issue where the reschedule button remained visible in projects with task dependencies disabled. The fix ensures the button is hidden when task dependencies are turned off, providing a cleaner and more consistent user experience. This improves project management clarity.
Original PR description
Steps to reproduce: - Install the project_enterprise module. - Go to project configuration and enable task dependencies. - Open project settings and disable task dependencies. Issue: The reschedule button remains visible even when task dependencies are disabled for the project. Cause: The visibility check for the reschedule control did not consider the project’s task dependency. Fix: Hide the reschedule button when task dependencies are disabled at the project. task-5150621 Forward-Port-Of: odoo/enterprise#97088
A recent update introduced errors in the XML format for exporting batch payments with mixed IBAN and Swedish payment methods. This fix reverts the problematic changes and simplifies the process by only generating the necessary zip file, ensuring accurate XML formatting for these payments. This resolves an issue impacting payment processing.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#102050
Forward-Port-Of: odoo/enterprise#100014This update addresses a missing dependency for the l10n_be_intervat module, which handles Belgian VAT reporting. The system now includes the necessary 'PyJWT' library and provides a helpful error message if it's not installed, ensuring the module functions correctly. This prevents potential errors for users.
Original PR description
The l10n_be_intervat module needs `PyJWT`, but it is not listed in external_dependencies. As we cannot change module dependencies in a stable version, this commit adds a try-except block regarding the import. In case the library is not installed, an error is logged to inform the user that they need to install the `PyJWT` module. Additionally, this commit updates the import of ImmatureSignatureError to come from jwt.exceptions instead of jwt. no-task Forward-Port-Of: odoo/enterprise#101583
This update ensures that the total account return balance is always displayed when there's a difference from the current period amount. Previously, this information was only shown if the return amount was lower. This change provides a more complete and accurate view of account return balances.
Original PR description
When this https://github.com/odoo/enterprise/pull/91886 got merged, It removed the accumulation of the balance in the return amount. Showing only the amount of the current period. Additionally, the total amount was shown if the amount was different. But, it was only being shown if it was less than the current period amount. The fix ensures it is always shown if the amount is different. task-5172274 Forward-Port-Of: odoo/enterprise#98150
This update fixes a calculation error in the MRR evolution dashboard that was causing 'Contraction' figures to be double-counted. The change ensures that MRR projections accurately reflect the true changes in recurring revenue by properly accounting for contraction and expansion trends. This improves the dashboard's reliability for financial reporting.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#101598 Forward-Port-Of: odoo/enterprise#96878
This update corrects a technical issue where type definitions for the WhatsApp module were not consistently updated alongside recent changes. This ensures that developers have accurate type information, leading to fewer errors and a smoother development process. It's a routine maintenance task to maintain code quality.
Original PR description
Various changes were done without updating the type definitions. https://github.com/odoo/odoo/pull/240002
This update fixes a bug where credit notes weren't being properly accounted for when settling invoices through the POS system. The change ensures credit notes are now correctly processed, allowing them to reduce the total amount settled, improving accuracy in financial reporting. This resolves a previous issue where credit notes were incorrectly interpreted as payments.
Original PR description
We had a bug when settling invoices and credit notes of a customer. The credit notes where not correctly computed. Steps to reproduce: ------------------- In accounting: * Create and confirm a customer invoice for a total of 10$. * Create and confirm for the same customer a credit note for a total of 2$. In POS: * In a seesion, open the customer selection menu. * In the burger menu at the right of our customer, select Settle invioces. * Select our invoice and credit note. > Observation: The credit note was previously seen as an amount to pay. Why the fix: ------------ Recomputing updates existing credit notes to use the signed residual logic. The domain change allows credit notes with negative pos_amount_unsettled to appear. After these changes, credit notes should appear in the "Settle invoices" dialog with negative amounts, and selecting them will create negative lines that reduce the total. opw-5257884 Forward-Port-Of: odoo/enterprise#101186
This update corrects a technical error that prevented Odoo from properly removing IoT records. The fix ensures that all necessary conditions are evaluated during deletion, preventing tracebacks and ensuring data integrity. This improves the stability and reliability of the IoT functionality.
Original PR description
For an unknown reason, when removing an IoT record, Odoo was evaluating only partly an `invisible` tag. The condition was `not version or version[0] == 'W'`. When deleting, `not version` was still false, but `version` in `version[0]` was undefined, resulting in a traceback. This is fixed using `'W' in version` instead. opw-5352092 Forward-Port-Of: odoo/enterprise#102065
23 changes
Enhancements to existing features
This update ensures that tax information, which the company pays to the government and later claims as a refund, is included in the invoice data sent for government reporting. This aligns with current tax regulations for India (l10n_in_edi) and provides accurate financial data for government transactions. It improves the reliability of exported data.
Original PR description
Following the task- https://www.odoo.com/odoo/project.task/4878805 and PR- https://github.com/odoo/odoo/pull/213931 Here we are not collecting tax from the customer but the company has pay taxes to the goverment and after that the company can claim refund for the taxes. So when we are sending data to goverment then we need to include tax part into the invoice total task-5369117 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238942 Forward-Port-Of: odoo/odoo#238641
This update ensures that the total tax amount paid by the company is included when generating reports for government tax filings (GSTR). Previously, only sales revenue was reported. This change accurately reflects the company's tax obligations and provides a complete picture for reporting purposes.
Original PR description
Here we are not collecting tax from the customer but the company has pay taxes to the goverment and after that the company can claim refund for the taxes. So when we are sending report data to goverment then we need to include tax part into the invoice total task-5369117 Forward-Port-Of: odoo/enterprise#101525 Forward-Port-Of: odoo/enterprise#101308
Resolved issues and error corrections
This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before currency calculations, preventing a division-by-zero error. This ensures smoother invoice processing and avoids disruptions to financial operations.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101695 Forward-Port-Of: odoo/enterprise#99518
This update resolves an issue where saving changes to the website footer template caused errors due to how customizations were being applied. The fix ensures that necessary CSS classes are always present, allowing users to successfully save their footer designs after making changes like switching templates or editing company names. This improves the overall stability and usability of the website builder.
Original PR description
The new footer templates had xpath selectors that were breaking in case the user changed some things in the footer. This is caused by a different order of evaluation after the copy is made to save the customized website view. This commit patches the view to add the class on which the xpath relies so that it is always present, thus the xpath always apply. Steps to reproduce: - Open website builder (on an new db) - Click on the footer - Change "Template" to "Mega" (or "Mega Columns", or "Mega Links") - Click on "Company Name" in the footer, and edit the text - Save - Bug: save fails because an xpath does not apply Commit adding "Mega": f252e096a3c8c432e601f6bae6fc1c11cd92c90b Commit adding "Mega Columns": aa0e653b5f641c735b4b6e25f80ae5d1d0a6dd94 Commit adding "Mega Links": 97ab0bc41bd3e5bd48b7e35e7d6918017d66004d task-5181309
This update fixes a technical error that occurred when removing IoT records in Odoo. The issue stemmed from an incomplete evaluation of a key tag, leading to a traceback. The fix ensures accurate record removal, improving system stability and reliability.
Original PR description
For an unknown reason, when removing an IoT record, Odoo was evaluating only partly an `invisible` tag. The condition was `not version or version[0] == 'W'`. When deleting, `not version` was still false, but `version` in `version[0]` was undefined, resulting in a traceback. This is fixed using `'W' in version` instead. opw-5352092
This update fixes an issue where shifts were incorrectly created for weekends and non-working days. The change ensures shifts are now automatically generated based on a resource's defined working schedule, improving planning accuracy and reducing manual effort.
Original PR description
Steps to reproduce: - Go to Planning. - Create a multi-shift for a resource for the entire week. - Shifts are created for all days, including weekends and non-working days. Issue: Shifts were created for the entire week, ignoring the resource working schedule, so weekends and non-working days were also included. Cause: Shifts were created without considering the resource’s working schedule, which led to inclusion of weekends and non-working days. Fix: Updated shift creation to align with the resource’s schedule, skipping weekends and non-working days. task-5051694
This update removes messages indicating the POS system's certification status. Currently, the POS is only certified to the LNE in version 18.0, and this change ensures that users don't see outdated certification information until a newer version is certified.
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 ensures that rental products are correctly unavailable when their associated employees are on time off. Previously, the system didn't account for employee absences, leading to incorrect availability displays. This fix improves the accuracy of rental product availability, enhancing the customer experience.
Original PR description
…navailabilties Before this commit, when an human resource is linked to rental product thanks to his role and take a time off at a certain day. The user inside ECommerce should be able to add that product when the resource is off (since there is no resource available) at the period chosen. However, that check does not take into account the time off taken by the resources linked to that service rental product. This commit makes sure the time off of the resources linked to the product are correctly taken into account to know if the service rental product is available at a specific period. task-5075698 Forward-Port-Of: odoo/enterprise#98165
This update fixes an issue where newly created employees were incorrectly marked as unavailable in the Planning Gantt view. The fix addresses a problem with how the system identified employee contracts, and now accurately reflects employee working periods based on their contract dates. This ensures accurate scheduling and resource allocation.
Original PR description
Steps to reproduce: - 1. Install Planning module. 2. Create a new employee without setting a contract start date. 3. Go to the Planning Gantt view by resource. Issue: - The Planning Gantt view…
Steps to reproduce:
-
1. Install Planning module.
2. Create a new employee without setting a contract start date.
3. Go to the Planning Gantt view by resource.
Issue:
-
The Planning Gantt view incorrectly grays out the entire schedule for newly created employees. It can also incorrectly gray out the initial days of a contract.
Cause:
-
1) With the introduction of `hr.version`, a version is now created for every employee by default. The logic to identify employees with a contract history was using a domain `[("employee_id", "in", ...)]`, which selects all employees, even those with no contract. This incorrectly flagged new employees as having a contract history, causing them to be marked as unavailable.
2) The view was using the computed `version.date_start` field. The computed `date_start` is calculated as the maximum of the version's creation date and the contract's start date. (e.g., contract starts Sep 1st, version created Sep 5th), the computed start date becomes Sep 5th, incorrectly graying out the period from Sep 1st to Sep 4th.
Fix:
-
1) The query that checks for an employee's contract history is now filtered by `('contract_date_start', '!=', False)`.
2) The Gantt view's working period calculation now uses the stored, `contract_date_start` and `contract_date_end` fields.
task-5058866
Forward-Port-Of: odoo/enterprise#94007This update resolves an issue where multi-step manufacturing processes involving by-products weren't correctly registering the by-product lines in the system. The fix ensures that by-products are properly added to the manufacturing process, creating the necessary pre-production and production lines. This improvement streamlines the 3-step manufacturing workflow.
Original PR description
### Steps to reproduce: - In the settings enable By-Products an Multi-step routes - Put your warehouse in manufacturing in 3 steps - Create two storable products: - Final Product (FP) with an empty…
### Steps to reproduce:
- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
- Final Product (FP) with an empty bom
- By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination
### Cause of the issue:
Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.
### Note:
The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f
opw-5350222
Forward-Port-Of: odoo/enterprise#101861
Forward-Port-Of: odoo/enterprise#101087This update resolves an issue where the reschedule button remained visible in projects with task dependencies disabled. The fix ensures the button is hidden when task dependencies are turned off, providing a cleaner and more intuitive user experience. This improves project management clarity.
Original PR description
Steps to reproduce: - Install the project_enterprise module. - Go to project configuration and enable task dependencies. - Open project settings and disable task dependencies. Issue: The reschedule button remains visible even when task dependencies are disabled for the project. Cause: The visibility check for the reschedule control did not consider the project’s task dependency. Fix: Hide the reschedule button when task dependencies are disabled at the project. task-5150621 Forward-Port-Of: odoo/enterprise#97088
This update fixes an issue where scanning a lot in a batch transfer incorrectly updated inventory lines. Specifically, when a subline without a lot was scanned after a related line was fully processed, the update prioritized the completed line instead of the intended subline. This change ensures that lotless lines are correctly updated during barcode scanning, maintaining accurate inventory tracking.
Original PR description
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create…
…f related line is complete ### Steps to reproduce: - In the settings enable Lots & Serials and Batch transfers - On the delivery operation types enable show reserved lots in the barcode tab - Create a storable product tracked by lots and put 10 x lot1 in stock - Create and confirm a delivery for 10 units - Create a batch transfer with your delivery - Process your transfer from the barcode app - Scan one unit of LOT1 and put in pack - Toggle sublines select the 0/9 subline without lots nor package - Scan LOT1 #### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9 ### Cause of the issue: Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot. opw-5340865 Forward-Port-Of: odoo/enterprise#101908 Forward-Port-Of: odoo/enterprise#101611
This update resolves a technical issue that occurred when toggling the 'is scanner' setting. The problem stemmed from a change in how the system communicated with devices, and the original error handling wasn't updated. This fix ensures the keyboard scanner functionality works reliably.
Original PR description
When toggling the "is scanner" toggle, we were getting a traceback. This comes from the switch from longpolling to `iot_http`, but the error handling wasn't adapted. opw-5408986
This update fixes a bug where credit notes weren't being accurately accounted for when settling invoices. The change allows credit notes to be properly deducted from totals, ensuring accurate financial reporting. This improves the reliability of the POS settlement process.
Original PR description
We had a bug when settling invoices and credit notes of a customer. The credit notes where not correctly computed. Steps to reproduce: ------------------- In accounting: * Create and confirm a customer invoice for a total of 10$. * Create and confirm for the same customer a credit note for a total of 2$. In POS: * In a seesion, open the customer selection menu. * In the burger menu at the right of our customer, select Settle invioces. * Select our invoice and credit note. > Observation: The credit note was previously seen as an amount to pay. Why the fix: ------------ Recomputing updates existing credit notes to use the signed residual logic. The domain change allows credit notes with negative pos_amount_unsettled to appear. After these changes, credit notes should appear in the "Settle invoices" dialog with negative amounts, and selecting them will create negative lines that reduce the total. opw-5257884 Forward-Port-Of: odoo/enterprise#101186
This update fixes an issue where documents without access were incorrectly displaying 'Restricted Folder' in the kanban view. The change ensures that users without access to a document's folder see 'Restricted' instead, improving clarity and usability. This was initially a workaround for AI prompt generation but has now been corrected.
Original PR description
Bug === In documents, when we don't have access on the folder of a document, we show "Restricted Folder" in the kanban view. For AI, because we don't want to add "Restricted Folder" in the prompt when the user has no access on the folder, we skip that in the compute of the display_name when we are in sudo. But display_name are always computer in sudo, so we never show "Restricted Folder".
This update ensures that users are prevented from adding rental products to their cart when the resource is unavailable during the selected rental period. Previously, the system didn't check availability if the ‘website_sale_renting_stock’ module wasn't installed, leading to incorrect booking attempts. This change improves the user experience by accurately reflecting resource availability.
Original PR description
Before this commit, when the user goes to the webshop to take a rental service with rental service unavailable at a certain period, the system does not block the user when the resource is not available during 2 hours in the period chosen by the user. The reason is because the hours are not checked when website_sale_renting_stock is not installed. This commit moves the code checking the time of the rental period made in website_sale_renting_stock in website_sale_renting to be able to have that verification for rental service used with planning to make sure the system will prevent the user to add the product in his cart when the resource is unavailable. task-5123239 Forward-Port-Of: odoo/enterprise#96241
This update fixes a calculation error in the MRR evolution dashboard that was causing 'Contraction' figures to be double-counted. The change ensures the dashboard accurately reflects the true net new MRR by properly accounting for contraction trends. This improves the accuracy of revenue forecasting.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#101598 Forward-Port-Of: odoo/enterprise#96878
This update prevents delays when the IoT connection fails. Previously, WebRTC would repeatedly attempt to connect, causing a 6-second fallback to longpolling. Now, if WebRTC fails, it's disabled for 20 minutes, ensuring smoother and faster communication with IoT devices.
Original PR description
Before this commit, WebRTC was always used as the first protocol when communicating with the IoT box. However, in an environment where it was not working, it would take 6 seconds to fallback to longpolling on every request. After this commit, if WebRTC fails, we don't try to use it again for 20 minutes. task-5412223
This update corrects a technical issue where the text displayed in the confirmation window of the mass mailing module was not included in the translation files. This meant the text wasn't available for translation into other languages, leading to a potentially inconsistent user experience. The fix ensures this text is now properly identified for translation, allowing for localization of the confirmation window.
Original PR description
Description of the issue/feature this PR addresses: The texts from the "confirm-title" attribute of a tag are missing from the POT files. Current behavior before PR: In this line there is a text (the caption of the confirmation window): https://github.com/odoo/odoo/blob/19.0/addons/mass_mailing/views/mailing_mailing_views.xml#L66 "Ready to unleash emails?" - This text is missing from the POT file. Desired behavior after PR is merged: * These texts will apeear in POT files * Someone needs to translated them * It will show up as translated texts in UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239328 Forward-Port-Of: odoo/odoo#239034
This update resolves an issue where a key calculation related to account reconciliation was unintentionally removed during a recent system update. This fix ensures accurate reporting of financial transactions and prevents potential discrepancies in accounting data. It's a necessary correction to maintain the integrity of our financial records.
Original PR description
During the forward port of: https://github.com/odoo/enterprise/pull/94552 the recompute of the checked field was removed. It needs to be added back no task id Forward-Port-Of: odoo/enterprise#102086
This update corrects a technical issue that was causing errors when processing accounts linked to companies that had been archived. The fix ensures that only active companies are considered during certain calculations, preventing the constraint error and maintaining data accuracy. This improves the stability of the accounting system.
Original PR description
When a company linked to an account is archived, it is filtered out from the `company_ids` many2many field due to the default `active=True` filter. As a result, `_read_group(groupby=['company_ids'])` groups such accounts under `False`, leading to a false-positive constraint error.
Add `('company_ids.active', '=', True)` to the domain in `_check_account_type_unique_current_year_earning` to consider only active companies.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug where locking a Point of Sale (PoS) with employee login and a blackbox would sometimes cause an error. The fix ensures the system verifies an employee is selected before attempting to update the clock-in date, improving PoS stability and reliability.
Original PR description
When a PoS was configured with "login with employees" and a blackbox, locking the pos then trying to select an employee raised a traceback. The PoS was trying to update the clock in date, but the employee was undefined. This is now fixed checking whether if the employee is set.
This update fixes an issue where the Partena export file incorrectly used the active company's code when generating reports for inactive companies. The change ensures the correct Partena code is included in the file, resolving a potential reporting discrepancy. Tests have been added to verify this fix.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786 Forward-Port-Of: odoo/enterprise#101960 Forward-Port-Of: odoo/enterprise#101110
16 changes
Enhancements to existing features
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched' within the UrbanPiper system. This prevents orders from being accidentally cancelled during POS closing, ensuring smoother order processing and reducing potential revenue loss due to cashier oversight.
Original PR description
In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. Task: 5261892
Resolved issues and error corrections
This update fixes an issue where the system incorrectly processed vendor bills with a zero unit price in Italian e-invoicing (l10n_it_edi). The fix ensures the system correctly incorporates the zero price from the XML, preventing errors and ensuring accurate e-invoice generation. This improves compliance with Italian tax regulations.
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#239419
This update corrects a bug in the expense import process for Odoo 18 and 19. Previously, the system incorrectly displayed a zero tax amount when importing expenses with a total amount including tax. The fix ensures that the tax amount is automatically calculated and accurately reflected in the expense record, aligning with the behavior of Odoo 17.
Original PR description
This commit adds expense import test when using total_amount_currency with price_unit missing. opw-5211041 --- **Workaround:** Use `total_amount_currency` instead of `total_amount`. Original bug…
This commit adds expense import test when using total_amount_currency with price_unit missing. opw-5211041 --- **Workaround:** Use `total_amount_currency` instead of `total_amount`. Original bug complaint described below. **Version:** Odoo 18.0, 18.4, and 19.0. The feature works as expected in Odoo 17. **Steps:** 1. On an Odoo 18 or 19 database, ensure an Expense Category (e.g., "Meals") is configured with a tax (e.g., 12% VAT, Price Included). 2. Prepare an import file (XLSX/CSV) with columns for Total (tax-included amount) and Category. 3. Go to Expenses > My Expenses > Actions > Import records. 4. Upload the file. Map the Total column to the "Total" field and the Category column to the "Category" field. 5. Complete the import and open the newly created expense. 6. Result: The Total is correct, the Category is correct, and the 12% tax is listed, but the **`Tax Amount`** field shows 0.00. 7. Expected Result (from Odoo 17): The system should auto-calculate and populate the Tax Amount based on the Total and the tax rate from the Category. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a performance issue where Odoo was unnecessarily calculating field values for inherited fields. By preventing these calculations, the system now runs more efficiently, especially when dealing with complex data relationships. This change improves overall Odoo responsiveness and stability.
Original PR description
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it…
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.
```
File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
views = get_views(
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
res = super().get_views(views, options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
result = super().get_views(views, options=options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
return super().get_views(views, options)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
result['models'][model] = {"fields": self.env[model].fields_get(
File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
return super().fields_get(allfields, attributes=attributes)
File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
description = field.get_description(self.env, attributes=attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
value = value(env)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
model._read_group_groupby(model._table, groupby, query)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
return super()._read_group_groupby(alias, groupby_spec, query)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
records = self.sudo().with_context(active_test=False).search_fetch(
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.DatabaseError: out of memory for query result
```
opw-5260147
upg-3444635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug where purchase orders weren't appearing in search results when linked to a vendor bill created by a company partner. The fix normalizes the search criteria to account for the difference between how purchase orders and vendor bills store partner information, ensuring accurate matching.
Original PR description
There are two issues: 1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user…
There are two issues:
1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.
Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order
1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.
2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear
Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483
1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.
2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8
Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995This fix resolves an issue where the system incorrectly used the main company during translation loading, leading to a ValueError when attempting to process VAT numbers for the BE localization. The update ensures the correct company context is used during translation loading, preventing this error and enabling proper localization functionality.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook self.env.registry._delayed_account_translator(self.env) File…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
self.env.registry._delayed_account_translator(self.env)
File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
env['account.chart.template']._load_translations(langs=langs)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
._get_chart_template_data(chart_template)
File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
data = super()._get_chart_template_data(chart_template)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
data = func(self, template_code)
File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
return func(*args, **kwargs)
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
id | name | chart_template | parent_id
----+---------------------+----------------+-----------
3 | C.R.O.Qu.E.T. S.A. | be_comp |
2 | KG5380 | be_comp |
1 | KNOWLEDGE GATE S.A. | lu |
(3 rows)
kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
id | model | module | res_id
----+-------------+--------+--------
2 | res.company | base | 1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```
- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239809This update fixes an issue where unnecessary slashes ('/') were appearing in tax reports' XML output when there was no comment provided. Removing this slash ensures the reports are correctly formatted and compatible with accounting systems. This change improves data accuracy and avoids potential reporting errors.
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#100033
This update resolves a critical bug in the Odoo Report Editor that caused crashes when Google Translate was active. By disabling translation specifically within the report editing iframe, the system now reliably saves report data without errors, ensuring a stable and functional editing experience.
Original PR description
Before this commit, when google translate was active on the current ReportEditor, it produced wrong data to save, and ultimately crashes. After this commit, since we disable the translation on the whole HTML element inside the iframe (that is only for the edited report), there is no error any more opw-5122924
This update corrects a bug where a procurement group wasn't consistently linked to sales orders when creating deliveries with multiple moves. The fix ensures that a procurement group is always associated with the picking, streamlining the process of managing delivery groups and improving order fulfillment accuracy. This resolves an issue impacting order processing efficiency.
Original PR description
### Steps to reproduce: - Create a picking with a move for any product #### Issue 1: > A procurement group is created and linked to the transfer - Add a second move on the picking and save #### Issue 2: > The procurement group of the picking is lost ### Cause of the issue: The `_set_sale_id` set method creates a procurment group and links it to the picking no matter if the `sale_id` is set or not. https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L90-L93 https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L100-L113 opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a visual glitch where dynamic website snippets would appear and disappear unexpectedly. The issue stemmed from a recent change in how snippets are styled, and this commit restores the original behavior of making snippets initially hidden, allowing content to determine their visibility. This ensures a consistent and reliable user experience.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523
This update resolves a minor visual glitch where the caret (cursor) within the record selector component was causing unexpected changes to 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 controlling prices within the POS system when utilizing the Swedish blackbox integration. Previously, this was a limitation, but now price control is enabled, aligning with requirements for the Swedish blackbox. The change reflects a difference in regulatory requirements compared to the Belgian blackbox.
Original PR description
Before this commit, user couldn't control the price in the POS if using the swedish blackbox. After this commit, user can control the price. It's not clear why the behavior at integration was set to this but it appears that it's not mandatory for swedish blackbox unlike the belgian one. opw-5253401 Forward-Port-Of: odoo/enterprise#100984
This update resolves an issue where users couldn't rename the "Help" menu item in the website helpdesk, encountering an error related to the 'website form' feature. Now, users can directly edit the name of this menu item, improving usability and flexibility within the helpdesk interface.
Original PR description
**Issue** It was not possible to rename the "Help" menu item, an error appeared with the message: "This URL is reserved for the helpdesk teams with 'website form' feature enabled.", even if the user was not trying to edit the URL. **Change** Allow the user to edit the menu item's name. opw-5375334 Forward-Port-Of: odoo/enterprise#101323
This update fixes an issue where duplicate downpayment lines were being created when settling POS orders with Avatax. The change ensures that a downpayment line is only created once, regardless of multiple sync operations, improving order accuracy and reducing potential accounting discrepancies. This resolves a bug impacting order settlement processes.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - create a SO in draft - open POS and and settle this SO (set a 10% down-payment line) - settle this order - open this SO Observation: - there are 2 down-payment lines for same tax Cause: - `sync_from_ui` from pos_sale keeps creating sol on each call to `sync_from_ui` Fix: - we check if there is already a line or not before creating a new line opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where loading demo data in a newly created company within the Appraisal module would fail due to permission restrictions. The fix ensures demo employee data is created within the current company, eliminating the access error and allowing users to successfully load sample data.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal` without demo data. 2. Create a…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi-company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.
sentry-7032880299This update resolves an issue where users could create invalid fields within Odoo's Web Studio report editor, specifically when designing the 'hr_timesheet' report. The fix prevents the generation of these invalid field nodes, ensuring reports render correctly and consistently. This improves the stability and usability of the Web Studio tool.
Original PR description
cf commit Forward-Port-Of: odoo/enterprise#99385
5 changes
Enhancements to existing features
This update optimizes how Odoo imports translations, reducing the size of the data processed and preventing potential memory issues. By focusing only on updated translations, the import process is now more efficient and stable, especially when dealing with large mail templates.
Original PR description
Before this commit, when importing the translations with the TranslationImporter object, the save method was building one big query per model, with each JSON object containing all the languages. On our server, where 36 languages are installed, this leads to big JSON objects, especially for some large mail templates. Recently, we even got MemoryErrors because of the soft memory limit being hit. The query was about 250MB long. In the function, we already have the current values, so it's easy to compare them to the new values, and only consider these in the query. Furthermore, there is no need to add the languages that aren't being updated. With this commit, we are building a slightly more complicated query, but it will receive much less data when the translations are updated frequently, as unchanged values will be ignored. Task-id: none
Resolved issues and error corrections
This update resolves a problem where invoices posted very early in the day (Chilean time) were incorrectly interpreted as being in the previous day, causing errors. The fix ensures invoice dates are handled correctly by freezing the test time and setting a fixed, compatible date, preventing this issue.
Original PR description
**Issue:** ```python File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation raise UserError( odoo.exceptions.UserError: The stamp date and time…
**Issue:**
```python
File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```
**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).
**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp
Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518This update fixes a rounding issue in the sales timesheet calculation, ensuring accurate remaining time displayed on Sales Orders. Previously, slight rounding errors accumulated, leading to inaccurate time overages. The fix eliminates intermediate rounding to provide a precise and consistent display of remaining time.
Original PR description
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order…
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order Line - Log 22:00 on timesheets Current behavior: Sales Order Line shows '-2:01 remaining' Expected behavior: Should show '-02:00' to reflect two hours overconsumed without rounding. Root cause: Python's float type follows the IEEE 754 double-precision standard, where only base-2 fractions can be stored precisely. Base-10 fractions cannot be represented exactly, introducing tiny rounding errors. During chained operations such as multiple conversions or subtractions, these small errors accumulate into larger discrepancies. The float_round() function uses a small constant epsilon to correct rounding noise, but as arithmetic chains grow, errors exceed epsilon's tolerance and it can no longer correct them. Since a single global epsilon cannot handle every case (small vs. large values, chained vs. single operations, or regressions), rounding drift is inevitable when rounding happens repeatedly. Fix: To prevent these rounding errors from compounding, the solution is to stop intermediate rounding altogether. By using conversions with round=False, all arithmetic is done in the base unit (hours) with full float precision, and rounding is applied only once when displaying the final value. This eliminates error accumulation and ensures consistent, drift-free results. task-5090240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where newly duplicated website pages weren't immediately visible in the page list. Users now need to reload the page list after duplicating a page to ensure the new page appears correctly. This improves the user experience and prevents frustration when working with page duplication.
Original PR description
Steps to reproduce: - Go in website page list - Select a page - Click on actions -> duplicate - Select a name - New page doesn't appear in the list, you need to reload to be able to see it task-5412167 https://github.com/odoo/odoo/issues/225299
This update addresses a bug related to conditional formatting previews in the spreadsheet component. It also incorporates the latest version of the o_spreadsheet library, ensuring users have the most current features and stability. This change improves the user experience and resolves a known issue.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/798a886ef1 [REL] 17.0.80 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5d0df51fb1 [FIX] cf: conditional formatting preview is truncated for nothing [Task: 5344000](https://www.odoo.com/odoo/2328/tasks/5344000) 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>