Daily updates from Odoo
Tuesday, September 30, 2025
10 changes · 17.0
Resolved issues and error corrections
The sale order payment confirmation test now uses the email template selected in system settings instead of assuming a fixed default. This makes the test better reflect real configurations and helps avoid false failures when businesses customize their sales confirmation emails.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Intrastat reports now take the region from the warehouse when it is defined, instead of always falling back to the company setting. This helps ensure cross-border goods reporting reflects the correct regional information and avoids inaccurate report lines.
Original PR description
## Issue: The Intrastat report currently uses the company region from settings instead of the warehouse region even when the warehouse has a region defined. ## Cause: The original…
## Issue: The Intrastat report currently uses the company region from settings instead of the warehouse region even when the warehouse has a region defined. ## Cause: The original 'stock.intrastat.report.handler' model defines a `_name` and implements `_fill_missing_values()` to override the company region with the warehouse region. However, this model does not appear to be called directly in the report and, in this particular case, its `_fill_missing_values()` method is not executed. For aggregated header lines, `_fill_missing_values()` cannot restore the region even if it were called, because these lines do not contain `invoice_ids` or `move_ids`. Without such identifiers, the warehouse cannot be determined post-query, so the company region was always used. https://github.com/odoo/enterprise/blob/03d9353d85ed80c6e44fd231e5340d2378af8c81/stock_intrastat/models/account_intrastat_report.py#L11-L37 ## Fix: Introduce a new model that _inherits from 'account.intrastat.report.handler' without a _name. The _fill_missing_values() method is kept in the model to preserve potential future usage, but in this case, the query changes already ensure that the region in the report is correct. ## Steps to reproduce: Note: Belgium localization is used here because it provides pre-defined regions that are easy to modify in the Settings App. - Install l10n_be_intrastat + sale_management + stock - Select a Belgium Company - In Settings, set Company Intrastat Region to "1 Flemish region" - Create a Product (Commodity Code: 01012100..., Weight: 10, Country of Origin: Belgium) - Set Warehouse > Intrastat region to "3 Brussels region" - Create and confirm a Sale Order for a French Customer (Tax ID: FR23334175221, Country: France) - Create and confirm the invoice - Open Accounting > Reporting > Intrastat Report - Select the Report: Intrastat (Goods) and This Month as date - Before the fix, the Region is 1 and it's the same for the details lines opw-5011272
This fixes a display issue where online shop prices could show unnecessary decimals for currencies configured to round to whole amounts. Customers now see prices consistently across product pages and configurator flows, matching the website's currency precision.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878
Rental product prices on the website now use the currency's configured decimal precision instead of always showing two decimals. This avoids confusing price displays for customers when a business uses currencies rounded to whole units.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429
This fix prevents users from removing the journal linked to an active payment provider. It helps avoid payment failures caused by incomplete journal settings, especially in multi-company or branch-company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an active payment provider; 2. create a branch company; 3. set payment provider's company to branch; 4. leave Payment Journal unchanged (parent company Bank); 5. go to Accounting / Configuration / Accounting / Journals; 6. open Bank journal; 7. open "Incoming Payments" tab; 8. enable the "Payment Provider" column; 9. unset the payment provider on the active provider's line & save; 10. attempt paying using the provider. Issue ----- > Error: psycopg2.errors.NotNullViolation: > null value in column "journal_id" of relation "account_payment" violates not-null constraint Cause ----- We shouldn't be able to change the related journal of active providers. Solution -------- Make the field read-only if the payment method is active. opw-5045000
Future time off balances now account for leave that employees have already taken when accrual limits are applied. This prevents overstated or incorrect projected balances on future dates, helping HR teams plan and communicate available leave more accurately.
Original PR description
Computing the future accrued days/hours would become incorrect when using a cap when total lifetime accrued allocation was higher than the cap. This caused issues when looking at how much accrued time an employee would have on a certain date where the accrued time would be correct on today, but become incorrect on any other future day. This was due to the fake allocation being used to compute the remaining time not considering the taken leaves, thus the cap was the maximum being considered across lifetime accrued time. opw-5059276
Customers viewing an online order with a manufactured product will no longer see the manufacturing date displayed twice. This keeps the order details page cleaner and avoids confusion in the customer portal.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009**
Published product tags now show in the eCommerce sidebar as soon as the product is published, even when variants are created dynamically. This helps shoppers find and filter products correctly without waiting for a specific variant to be generated.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an attribute which creates variants dynamically; 2. create a product with two or more dynamic attribute values; 3. add a new tag to the product; 4. publish the product to eCommerce. Issue ----- The tag doesn't show up in the side-bar until after a product variant has been created. Cause ----- The tags are searched based on `product_ids` instead of `product_template_ids`, leading to tags assigned to dynamically created product variants not showing up until a variant has been created. Solution -------- Search tags based on `product_template_ids.is_published` as well as `product_ids.is_published` (in case of `addition_product_tag_ids`). opw-4985989
This fixes the Spanish accounting setup so account 411 is classified as a current liability. The change helps ensure financial reports and accounting balances use the correct category for this account.
Original PR description
Account 411 should be of 'liability_current' type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Chilean bank reference data rely on the country's stable internal identifier instead of its display name. It prevents module updates from failing when country names have been changed or corrupted in a database, improving reliability for Chile localization upgrades.
Original PR description
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted: ```SQL pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN…
`res.country` records are `noupdate` by default, which means that changes such as the following are not reverted:
```SQL
pied@(none):pied_3131231> SELECT c.name->>'en_US' FROM res_country c JOIN ir_model_data d ON d.res_id = c.id AND d.model = 'res.country' AND d.module = 'base' AND d.name IN ('cl', 'co')
+----------+
| ?column? |
|----------|
| COLOMBIA |
| Colombia |
+----------+
```
Note: in this specific, the change is clearly an error introduced in the data. Still, the error it produces (which follows) can be avoided by referring to the xmlid, instead of the record name.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
File "<decorator-gen-6>", line 2, in new
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
load_modules(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 455, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 226, in load_module_graph
load_data(env, idref, 'update', kind='data', package=package)
File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 79, in load_data
tools.convert_file(env, package.name, filename, idref, mode, noupdate, kind)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 624, in convert_file
convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-18.4/odoo/tools/convert.py", line 680, in convert_csv_import
raise Exception(env._(
Exception: Module loading l10n_cl failed: file l10n_cl/data/res.bank.csv could not be processed:
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
No matching record found for name 'Chile' in field 'Country'
```
upg-3131231