Daily updates from Odoo
Friday, September 26, 2025
13 changes · 17.0
Resolved issues and error corrections
Rental product pages now keep showing the main product's pricing table after an optional product dialog is opened and closed. This prevents customers from seeing the wrong rental prices, reducing confusion during checkout.
Original PR description
Steps: - Install eCommerce and Rental module. - Create a product with option product with both product contains different renting pricing. - Go to product in the website. - Click on add to cart it will open dialog with optional product. - Close the dialog. Issue: - Price table has optional product's pricing instead actual product. Cause: - Updating combination always trigger pricing table update and in optional product dialog update combination last calls for optional product and thus it update pricing table to optional product pricing. Fix: - Only update pricing table if the combination of main products update. Issued PR: https://github.com/odoo/enterprise/pull/32614 opw-5012075 Forward-Port-Of: odoo/enterprise#94758
Printed invoices now show the correct early-payment amount when both an early payment discount and cash rounding are applied. This prevents customers from seeing a slightly incorrect amount due on invoice documents.
Original PR description
**Steps to reproduce** - Create a tax of 8.1% - Activate and create a cash rounding with rounding precision 0.05 - Use the existing '2/7 Net 30' payment term (or create a new 2% early discount one) - Create a new invoice: - Add payment terms - Add cash rounding method - Add line with price 50, 8.1% tax - Invoice total will be 54.05 **Issue** Print the invoice: The invoice will show "$ 52.97 due if paid before 09/12/2025" However 52.97 is the amount with just the 2% early payment discount applied With cash rounding applied, it should display 52.95 This occurs because when retrieving the amount from the invoice template the system applies only the early payment discount opw-4914545 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4914545)
Accrued expense entries for purchase orders now show the tax-exclusive amount after applying line discounts. This prevents overstated amounts when reviewing or creating accrued expenses for discounted purchases.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848
The Spanish Mod 349 tax report now correctly shows the underlying invoice lines when users audit the summary for intra-community operations. This helps accounting teams verify reported EU transaction amounts without missing supporting details.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813
Website product pages now show the correct price when a customer's tax rules change how taxes are applied. This prevents small rounding errors, such as a $10 item appearing as $10.01, improving price accuracy for shoppers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. have two 15% taxes, one price-included, one price-excluded; 3. create a $10 product that uses the price-included tax; 4. create a fiscal position that maps the included tax to excluded one; 5. assign the fiscal position to the public partner; 6. open the product's shop page as public user. Issue ----- The price gets displayed as $10.01. Cause ----- When applying the taxes to the price, small errors are introduced by rounding the base price before doing the tax calculations. Solution -------- To circumvent issues like these, commits 143ec3739196f and 6045061f818a0 added the `round` & `round_base` context values respectively. By settings these to `False`, we can prevent intermediate rounding that may introduce errors like these. opw-4945752
This fix prevents small rounding differences from building up during inventory revaluation. It helps avoid incorrect negative remaining values, improving the reliability of stock valuation and related accounting figures.
Original PR description
Before this commit, the remaining_value_unit_cost was rounded before any computation. In the case where the numer of layers with remaining value and remaining quantity increase, the rounding error introduced by that rounding quickly explodes, leading to a negative remaining_value during revaluation computation. After this commit, the remaining value is rounded at the end, after the computations and the checks. This ensures that the rounding error remains constant and does not accumulate over the execution of the method. opw-4901966
A timesheet attendance report query now correctly identifies the employee field it needs to use. This prevents database comparison errors that could block affected Odoo upgrade requests.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
Sales orders now ignore archived projects when deciding whether to show the project shortcut button. This prevents users from seeing a project indicator when only inactive projects are linked, reducing confusion in order follow-up.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817
Payment terminal messages printed at the bottom of POS receipts now use the correct font sizing. This makes the text easier to read on printed receipts and keeps it consistent with the on-screen preview.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where pages could fail to load after setting an SEO cover image and changing or using a website domain. The cover image is now stored in a safer relative format, helping affected website pages display normally instead of showing a server error.
Original PR description
Scenario: - in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize SEO > Cover Image) - set a domain on the website - go to the page with the cover image Result: an error 500 with this…
Scenario:
- in 19.0 add a website_meta_og_img (Website > Editor > Site > Optimize
SEO > Cover Image)
- set a domain on the website
- go to the page with the cover image
Result: an error 500 with this traceback error:
```py
File "addons/website/models/mixins.py", line 92, in get_website_meta
opengraph_meta['og:image'] = url_join(root_url, self.env['ir.http']
._url_for(self.website_meta_og_img or opengraph_meta['og:image']))
File "odoo/tools/urls.py", line 59, in urljoin
raise ValueError("Extra URL must use same scheme and host as base,
and begin with base path")
```
Cause: since 19.0 977e62d91f3e8235e251e9d21b08f53db1856c6b werkzeug
url_join is replaced by odoo urljoin, which requires that the path that
is appended has no host, or the same host. Since the current code saves
the scheme and host of the website_meta_og_img, if the URL is different
than the saved one (because of domain or another reason), we get an
error.
Fix: save a relative URL instead of an absolute one.
opw-5101875
opw-5102079
opw-5105258
opw-5107443
opw-5111474
opw-5112343
opw-5113844
opw-5114544
__Note:__ I rebased on 17.0 since the code has not changed since then, the problem just become visible because of the urljoin change.
__Note:__ I created a upgrade PR to fix the issue for migrated database https://github.com/odoo/upgrade/pull/8494Project task lists now keep the allocated hours field visible and editable even when its value is zero. This makes it easier for users to update multiple task allocations without being blocked by hidden cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288
This fix ensures online store orders keep the correct pricelist based on the shopper's GeoIP country, even after a visitor creates or signs into an account without an address. It prevents customers from being assigned a pricelist that is not valid for their location, improving pricing accuracy during checkout.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198
Fixed an issue where the rental schedule could omit later rental orders when the same serial-numbered product was rented again. Businesses can now see the full rental workload and availability for those items, preventing undercounting in planning.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247