Friday, December 12, 2025
18 changes · saas-18.2
Enhancements to existing features
Odoo now includes an identifier in PayPal payment flows so PayPal can recognize transactions coming from Odoo. This improves traceability and partner reporting without changing the payment experience for users.
Original PR description
PayPal requested that we add an identifier so that they know which transactions are coming from Odoo for better trackability. task-5358321 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237336
The point of sale loyalty system now stops checking reward products once it has found a valid free product option. This reduces unnecessary processing and can make loyalty reward handling faster when several reward products are configured.
Original PR description
Before this commit, the computation of potential free product quantities looped through all reward products even after finding a valid one. This led to unnecessary calculations and performance degradation, especially when multiple reward products were involved. opw-5268991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239442
This update enhances the formatting of tax amounts in invoices for the Co-dian localization module. It standardizes the float format used in account_edi_common, ensuring accurate and consistent reporting for tax calculations related to Co-dian regulations. This improves the reliability of financial data for Co-dian users.
Original PR description
Forward-Port-Of: odoo/enterprise#101288
Resolved issues and error corrections
Sales order users no longer see the edit configuration option for combo products when the required product information has been removed. This prevents an error and keeps order editing smoother in the Sales app.
Original PR description
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management`…
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management` with demo and create a new SO. - Add a combo product and remove the combo name and click Edit Configuration (pencil icon). Error: `TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'` Cause: - When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered. Solution: - Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present. Similar PR for reference: https://github.com/odoo/odoo/pull/217464 [1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238536
This fixes an internal logging issue where certain structured message details could be lost or cause formatting errors. It improves reliability of error reporting, helping support and operations teams diagnose issues more accurately.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239560 Forward-Port-Of: odoo/odoo#239410
Fixed an issue where sale order PDFs using the DIN 5008 layout could show the customer address twice. This keeps printed quotations and orders cleaner and avoids confusion when customer address display is disabled.
Original PR description
## Issue: When DIN5008 is selected as the document layout, printing a Sale Order may show the customer address twice ## Cause: The address is first added by `external_layout_din5008`, then again by `report_saleorder_document` This duplication only makes sense when the partner address differs from the invoice or delivery address If the Customer Addresses setting is disabled, displaying it multiple times is unnecessary ## Steps to reproduce: - Install a company using DIN 5008 (e.g., l10n_de) - Select the DE company and go to Settings - Disable `Customer addresses` and ensure the document layout is set to DIN 5008 - Create a Quotation with any customer and product - Print the PDF → the address appears twice before the fix opw-5176593 Forward-Port-Of: odoo/odoo#235441
Coupon emails and their attached documents now show expiration dates in the customer’s preferred date format. This avoids confusing technical-looking dates and improves clarity for customers using languages or regions with different date formats.
Original PR description
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount…
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount & loyalty 5. Create a record with program type coupons 6. Generate a coupon for that AU contact with an expiration date Issue: The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format. Cause: We are not using a formatted date according to the customer before: Customer with English AU language <img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" /> <img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" /> After: <img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" /> <img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" /> opw-5247621 Forward-Port-Of: odoo/odoo#237880
This fix prevents Chilean invoices from failing during confirmation when the invoice total is zero and a foreign currency is used. It adds a safeguard so users can confirm valid zero-value invoices without encountering an error.
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#239063
Forward-Port-Of: odoo/odoo#235252Cashiers now see a notification if they try to close a POS session without being the selected logged-in employee. This helps avoid confusion and makes it clearer why backend access or session closing is blocked.
Original PR description
After this commit, when attempting to close a POS session, if the logged-in employee is not selected, a notification will inform the user. This prevents confusion. opw-5244818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234741
This fixes an internal script conversion issue that could shift debugger line numbers when certain import statements followed a blank line. Developers troubleshooting Odoo JavaScript will now see line numbers that better match the original source, reducing confusion during debugging.
Original PR description
Steps to reproduce
==================
- Create a js file with a blank line followed by an unnamed import
```js
import { mailModels } from "@mail/../tests/mail_test_helpers";
import "@account_accountant/components/bank_reconciliation/list_view/list_view_many2one_multi_edit";
import "@account_accountant/components/bank_reconciliation/list_view/list";
debugger;
```
- Open the devtools
=> The debugger will be off by one line
Cause of the issue
==================
When remplacing unnamed imports by a require statement, the leading whitespace was not preserved.
Solution
========
We add back the captured space. This is done for every other replacement.
Forward-Port-Of: odoo/odoo#239531This update ensures that a 'partner ID' is always set when processing SEPA payments. Previously, a missing partner ID could cause errors, preventing the creation of batch payments. This change improves the stability and reliability of our payment processing system.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880 Forward-Port-Of: odoo/enterprise#98249
This update resolves a limitation preventing non-administrator users from utilizing the delivery_usps_rest module. By implementing sudo() calls, the module now grants necessary access to the USPS Rest API, expanding functionality without requiring elevated user permissions. This improves usability for a wider range of users.
Original PR description
Non-admin users are currently unable to use the delivery_usps_rest module because several fields are limited to the "base.group_system" group. It's obviously not feasible to give everyone the "Role / Administrator" role. This PR makes necessary sudo() calls the same way that delivery_ups_rest does. Forward-Port-Of: odoo/enterprise#101163
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 transactions.
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#101587 Forward-Port-Of: odoo/enterprise#99518
This update resolves an issue where long text inputs within the Odoo Web Studio application would overflow, causing display problems. Now, long text is automatically truncated, ensuring a clean and usable interface for users. This improves the overall stability and user experience of the Web Studio module.
Original PR description
**Before this commit:** Long input text overflowed and was not truncated. **After this commit:** Long input text is now properly truncated, preventing overflow. task-5240113 Forward-Port-Of: odoo/enterprise#99535
This update fixes an issue where internal transfers using barcode scanning wouldn't correctly assign a result package when the package already contained items. The fix ensures that all packages, regardless of content, can be assigned as the result package during internal transfers, improving the efficiency of inventory management.
Original PR description
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable…
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable "Packages" and "Storage Locations" settings; 2. Create two packages with some content in WH/Stock/Shelf 1; 3. Create an empty package; 4. Create an internal transfer directly from the Barcode app; 5. Scan Shelf 1 barcode and scan first package; 6. Scan the empty package => It's assigned as the result package; 7. Confirm the operation; 8. Create another internal transfer; 9. Scan Shelf 1 barcode and scan second package; 10. Scan the no more empty package => This time, it's not assigned as the result package. Reason ====== A package was assigned as the result package only if one of the following conditions is matched: 1. The scanned package is empty (it's what's happening in 6.); 2. The selected line has no result package yet and the scanned package is in the selected line's destination location. Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.) Fix === For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package. [opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234) Forward-Port-Of: odoo/enterprise#101853 Forward-Port-Of: odoo/enterprise#101357
This update removes messages indicating the POS system's certification status. Currently, the POS is only certified by the LNE in version 18.0. This change ensures consistent messaging until a higher version with full certification is released.
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
This update prevents HR users from receiving unnecessary reminder emails. Previously, reminders were triggered by time-off requests or public holidays, even if the user didn't need to submit a timesheet. Now, reminders are only sent for active timesheet entries requiring user input, streamlining the process.
Original PR description
**Steps to reproduce:** - Install timesheet_grid_holidays - Create a user with no timesheet access - Create a leave and approve it as a manager - Set up employee reminders in timesheet settings - Run the timesheet reminder scheduled action **Issue:** HR users without timesheet app access or who haven’t submitted timesheets in the past 3 months were still receiving reminder emails. **Cause:** When a time-off is approved or a public holiday is recorded, it generates timesheet entries, which causes reminder emails to be sent incorrectly. **Fix:** Filter out time-off and public holiday entries when sending reminders. Now, reminders are only sent for actual timesheets that require user input. task-5085790 Forward-Port-Of: odoo/enterprise#95450
This update fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The change ensures that shifts are updated in real-time after being unscheduled, improving scheduling accuracy and reducing user frustration. This enhances the overall planning process.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381 Forward-Port-Of: odoo/enterprise#97108