Thursday, December 4, 2025
7 changes · saas-18.3
Enhancements to existing features
This update enhances the integration with Adyen, the payment processor, by adding crucial information about our platform. This ensures accurate transmission of key details during payment requests, leading to smoother and more reliable transactions. A new test has been implemented to confirm the successful completion of these payments.
Original PR description
Add applicationInfo to the payload sent to Adyen, ensuring that externalPlatform is correctly transmitted. A test was added to verify that applicationInfo is present in the payload and that the payment request succeeds as expected. task-5157863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237008 Forward-Port-Of: odoo/odoo#233075
Resolved issues and error corrections
This update fixes an issue where scanning a lot multiple times during barcode picking would incorrectly create a backorder. The change ensures that quantity updates are applied correctly to the relevant lines, preventing unnecessary backorders and improving order fulfillment accuracy. This resolves a bug related to how the system processes lot scans.
Original PR description
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm -…
**Steps to reproduce:** - create a product tracked by lot - create a lot with a quantity of 2 - create a new sale order - add two sale order lines, both for a quantity of 1 of the product - confirm - open the picking in barcode - scan the stock location - scan the lot - scan the lot another time - validate **Current behavior:** a backorder is created **Expected behavior:** No back order should be created **Cause of the issue:** After scanning the lot for the first time we have the following situation: two lines : - one with a quantity of 1, qty_done of 1 and reserved_uom_qty of 1 - one with a quantity of 1, qty_done of 0 and reserved_uom_qty of 1 both lined grouped in a parent line with quantity of 1 qty_done of 1 and reserved_uom_qty of 2 All of this is correct. when scanning the lot for the second time: _findLine iterates through the lines to select the right line to use. _findLine calls _lineIsNotComplete on the first line to check if it's complete (this first line is complete). https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_model.js#L1684 But _lineIsNotComplete will actually do the check on the parent line (which is not complete), so the return value will be true. https://github.com/odoo/enterprise/blob/58d55868750b827a9d5ebd8b4ab2cc23c4445eca/stock_barcode/static/src/models/barcode_picking_model.js#L1338 As a consequence, the quantity will be added in the first line and we will have a qty_done of 2 in the first line and a qty_done of 0 in the second line. Which will lead to the creation of a back order opw Forward-Port-Of: odoo/enterprise#100626 Forward-Port-Of: odoo/enterprise#99774
This update resolves an issue in the German localization (l10n_de) module where changing a product's cost in a multi-company environment would trigger tax access errors. The problem stemmed from fetching taxes in a privileged (sudo) environment, leading to incorrect data. This fix, implemented in Odoo 19.0, corrects this by removing the privileged environment, ensuring accurate tax calculations.
Original PR description
from v18.0 to v18.4, in a multi-company environment, when a product with no income/expense account had its cost changed, all the taxes for other companies were being fetched which caused access errors when trying to view it after a manual save. This happens because the fetch is happening in a sudo environment because the stock valuation layer was being created as sudo, so all taxes were being fetched and probably because of cache pollution they were not being filtered properly, this is not happening in v19.0 because the stock valuation layer was removed, so everything is being called in a normal user environment, refer to this commit-08b62a4 task-5117882 Forward-Port-Of: odoo/odoo#236931
This update resolves a problem where email templates were being incorrectly parsed, leading to errors. The fix ensures that all HTML elements, except for void elements, are properly closed, improving the reliability of email content generation. This prevents template rendering issues when sending emails.
Original PR description
**Step to Reproduce:** - install Subscription (with demo data) - try to edit `Subscription: Payment Reminder` email template **Observation:** - Traceback for faulty template **Cause** For outgoing…
**Step to Reproduce:**
- install Subscription (with demo data)
- try to edit `Subscription: Payment Reminder` email template
**Observation:**
- Traceback for faulty template
**Cause**
For outgoing mails, we are using output_method = 'xml' when normalizing html content
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/odoo/orm/fields_textual.py#L580-L587
when this content is parsed using DOMParser in browser,
https://github.com/odoo/odoo/blob/cb5176df98490ef04c0aac481f010bd2ac2f2424/addons/html_editor/static/src/html_migrations/html_upgrade_manager.js#L61-L63
we might get different result.
For a very basic template like this:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''" />.
</t>
<t t-else="">
<span>some text</span>
</t>
</div>
```
when parsed using Domparser(), return a faulty template:
```
<div>
<t t-if="ctx.get('error')">
<pre t-out="ctx['error'] or ''">.
<t t-else="">
<span>some text</span>
</t>
</pre>
</t>
</div>
```
Issue roots because of use of self-closing tags, which are valid for xml but not for html
**Fix:**
- we forcefully replace all self-closing tags(which are not void elements) with a closing tag.
- see list of void elements https://developer.mozilla.org/en-US/docs/Glossary/Void_element
opw-5234345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where promotion rewards automatically added to shopping carts couldn't be removed. The fix ensures that removing a promotion reward from a cart line now functions correctly, improving the user experience and preventing unwanted rewards from remaining in orders. This change was made to address a bug impacting order management.
Original PR description
Steps: - Add a loyalty program of type promotion - Program trigger should be Automatic - Go to Shop > Add a product that triggers the reward of promotion - Try to remove the promotion added from the cart lines Issue: - Remove does not work for the automatically applied promotion reward Cause: - Context is not properly passed to the unlink method that removes the cart line of the promotion reward. - Since the unlink method is not receiving context properly, removal is bypassed Fix: - Instead of adding context in `self`, adding it directly in the `order_line` context fixes the issue. task-5076061 Forward-Port-Of: odoo/odoo#226789
This update resolves an issue where the Point of Sale app for Mexican companies was incorrectly flagging an error when the 'Invoice to Public' setting was set to 'Yes' for customers without a country or zip code. The fix ensures this setting is properly updated, preventing the error and allowing users to correctly generate public invoices as required by Mexican regulations.
Original PR description
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice…
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101162
Forward-Port-Of: odoo/enterprise#99871This update resolves an error that occurred when creating time off requests. Specifically, the system would fail if a start date was removed and then the employee was changed. The fix ensures the system only checks for past dates when a start date is provided, preventing the error.
Original PR description
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and…
Currently, an error occurs when creating a time off request for an employee. Steps to Reproduce: - Install the `hr_holiday` module. - Go to `Management > Time Off`. - Create a `new time off` and `remove the start date`. - Now `change the employee`. `AttributeError: 'bool' object has no attribute 'date'` This error occurs when creating a time off request for an employee. If the start date is removed and then the employee is changed, the compute method [1] runs to determine whether the time off can be approved and to update the states [2]. During this process, the system checks whether the time off date is in the past, and since the start date is missing, it results in the error [3]. This commit ensures that the system only checks whether the time off is in the past when a start date is provided. [1]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L594-L597 [2]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1279 [3]- https://github.com/odoo/odoo/blob/aa53689d3c593a8a41479c51edc2b01e3c284f96/addons/hr_holidays/models/hr_leave.py#L1237 No Task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr