Thursday, September 4, 2025
10 changes · 18.0
Resolved issues and error corrections
This fix prevents product pages from crashing when users edit translations in a secondary website language. It corrects how translated read-only values are cached, improving reliability for multilingual websites and reducing 500 error pages for shoppers and editors.
Original PR description
Scenario:
- activate another lang on website
- go to a product page (eg. /shop/1)
- swith to secondary language and edit translations
Result: a 500 error page is shown with error:
Error while render the template
ValueError: Compute method failed to assign
product.template.attribute.value(378,).name
Template: website_sale.product
Cause:
From 18.0 40d79d6c869e2fdd0e85c372aa589373e6607975 used an underscore
prefixed lang in cache, when it should have only done so if the field
had a callable translate.
note: to have the issue, the field needs to also be readonly or we use
update_raw with the non underscore prefixed language.
opw-5039727
opw-5040036
opw-5043034
opw-5043718
opw-5045525
opw-5049079
opw-5049139
opw-5045575
opw-5049531
opw-5049811
opw-5052090
opw-5052930
opw-5053949
opw-5057485
opw-5058659
opw-5059343
opw-5059987
opw-5060138
closes #[225192](https://github.com/odoo/odoo/pull//225192)This fixes an error that could prevent certain website pages created through Studio from loading when they included SVG images. SVG files are now handled correctly, avoiding a broken page experience for users.
Original PR description
Steps to reproduce ================== - Install `hr_contract_salary,web_studio,website` - Go to Employees - Open studio - Click on "Model pages" - Create a new record - Save it - Click on "Go to Website" Error while render the template ValueError: Non-image binary fields can not be converted to HTML Cause of the issue ================== It crashes because the svgs are not supported in the pillow library: https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#fully-supported-formats Solution ======== Skip the image verification if the image is an svg opw-4820322
Fixed an issue where extra hours time off that was refused and later approved was not deducted correctly. This prevents employees from repeatedly requesting more extra-hours leave than they should have available.
Original PR description
Steps to reproduce: - On the time off dashboard, create a new leave with the type "Extra hours" - Click on the request again, refuse the request - Click on the request, and now approve the time off -If you now try to create a new time off with the type "Extra hours", you'll notice that the duration of the previously "refused then approved" time off is not taken into account Reason: The action tied to the "Approve" button was wrongly named in the inherited hr_leave model of the hr_holidays_attendance module, which prevented the computation for the approval to be taken into account. How it was fixed: Correcting the name allowed the function to be called properly and the calculation is now performed correctly. Task ID: 5051271
This fixes an issue where users could get a record mismatch error after editing a task description, switching tabs, then editing again before saving. The editor now keeps the full set of content IDs during reset, preventing valid changes from being blocked.
Original PR description
Problem: When editing a task description, if changes are made and then the tab is switched before returning to the description tab and making further edits, saving raises a record ID mismatch error. Cause: Switching tabs destroys the editor. On reset, the editor retrieves IDs locally from the record and strips them down to the last one. This causes the loss of the last ID known by the server. Solution: On reset, append all IDs from the content instead of only the last one, since the server ID might not be the most recent. Steps to reproduce: 1. Open a task. 2. Change the description. 3. Switch to another tab and return to the description. 4. Make further changes. 5. Save. - An error occurs due to record ID mismatch. opw-5012949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where editing translations could crash when product-related fields were loaded in another language. The cache now uses the correct language context, helping translated website and product content load reliably.
Original PR description
**step to reproduce** - install website_sale and install french language - open a product page and change language to fr - open editor, click on Edit -> translate **Observation:** - we get a…
**step to reproduce**
- install website_sale and install french language
- open a product page and change language to fr
- open editor, click on Edit -> translate
**Observation:**
- we get a traceback
```
File "/home/odoo/odoo/codebase/odoo/18.0/addons/product/models/product_product.py", line 522, in _compute_display_name
variant = product.product_template_attribute_value_ids._get_combination_name()
File "/home/odoo/odoo/codebase/odoo/18.0/addons/product/models/product_template_attribute_value.py", line 173, in _get_combination_name
return ", ".join([ptav.name for ptav in ptavs])
File "/home/odoo/odoo/codebase/odoo/18.0/addons/product/models/product_template_attribute_value.py", line 173, in <listcomp>
return ", ".join([ptav.name for ptav in ptavs])
File "/home/odoo/odoo/codebase/odoo/18.0/odoo/fields.py", line 1312, in __get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign product.template.attribute.value(5,).name
```
**Simple way to reproduce a issue using shell**
```
pt = env['product.template']
y = pt.browse(12)
y.with_context(edit_translations="1").uom_name
```
Traceback
```
if self.readonly and not self.store:
-> raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
# fallback to null value if compute gives nothing, do it for every unset record
false_value = self.convert_to_cache(False, record, validate=False)
ValueError: Compute method failed to assign product.template(12,).uom_name
```
**Cause:**
- When the context includes `edit_translations` or `check_translations`,
env._lang returns `_{lang}` (e.g., _en_US).
- currently, `_{lang}` is used as a cache key for compute/related fields
as they are not dirty and translatable
- however, the Field.__getter__ fails for such fields, as `missing_recs_ids` looks for the
records for `lang` as cache key, Since the cache is updated with `_{lang}`,
the lookup fails and translated fields are not retrieved correctly
**Fix:**
do not use context dependant lang, when updating cache
opw-5043034
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes historical stock availability more accurate when checking quantities for a specific warehouse location. It prevents Odoo from showing stock as available in the past when a later stock move into that location should be excluded, helping teams rely on inventory reports for backdated checks and audits.
Original PR description
Problem, Odoo check the stock.move to decrease the quantity if we want available product quantity in a past. If i valid a stock move for new product with location_dest_id = A and stock.move.line with location_dest_id = B (B child of A) and i check the quantity in a past in B location, Odoo return the quant quantity in B location without decrease the last move line. Before fix: product.with_context(location=B).qty_available = 1 product.with_context(to_date="2025-09-01", location=B).qty_available = 1 After fix: product.with_context(location=B).qty_available = 1 product.with_context(to_date="2025-09-01", location=B).qty_available = 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an invoicing issue where delivered combo products could be missing from customer invoices. This ensures sales teams can invoice delivered combo items accurately without manual workarounds.
Original PR description
Steps: - Create a combo product with all the product in choices should have invoice policy `delivery`. - Create SO with that product. - Confirm SO and validate delivery. - Create invoice. Issue: - Combo line is not showing in invoice. Cause: - When validating delivery of line compute of `qty_to_invoice` only call for other lines not combo lines because we are not changing `qty_delivered` on combo line. Fix: - Add combo lines related to other lines in `combo_lines` variable instead of just checking combo lines in `self` as we do not compute other fields(qty_delivered, qty_invoiced) for combo line orignal PR: https://github.com/odoo/odoo/pull/203131 opw-4640087
This fixes a calendar issue where the “+ more” link could be blocked on weekend days in day or week views when viewing everybody’s calendar. Users can now open the full list of events instead of accidentally starting a new event.
Original PR description
Description of the issue/feature this PR addresses: Related to this ticket [4879528](https://www.odoo.com/odoo/project.task/project.task/4879528) When configured to have "everybody's calendar"…
Description of the issue/feature this PR addresses:
Related to this ticket [4879528](https://www.odoo.com/odoo/project.task/project.task/4879528)
When configured to have "everybody's calendar" selected, for day and weekly view, the "+x more" clickable link is overlapped by a "fc-daygrid-bg-harness" div, making it impossible for the user to select click this link. The fix serves to push the overlapping div back to ensure the user can click on the more link.
Note: This issue can be reproduced by using a weekend day, as it by default will have the overlapping div since it is a non business day.
Steps to reproduce issue:
- Select day / week view on calendar view
- Create 6+ more events on a weekend day
- Try and click the "+x more" button
Current behavior before PR:
The user could not click on the "+x more" link and instead the wizard to create a new calendar event appears.
Desired behavior after PR is merged:
The list of events appears when clicking the "+x more" link instead of the wizard.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEvent pages with titles in languages such as Chinese now identify the correct event when users edit them. This prevents the system from opening or updating the wrong event due to numbers in encoded web addresses.
Original PR description
Issue: The Website Event page uses a matching regex to get the event id from the url. URLs are formatted like: '/event/[event-title]-[event-id]/register' The event-id is recovered from the url by matching on the first number that is not followed by a word character. However, for non-latin event titles (e.g. Chinese), the characters are converted using '%' characters and numbers (e.g. '%E6%88%91%E'). The regex consistently fails to get the event id in this case, and returns incorrect IDs. Steps to reproduce: 1. Install `website_event` and go to the website view of any event. 2. Edit the event, to add a Chinese title 3. Save, and try to edit again the same title. Solution: The regex is modified to look for the first number that is followed by either a "/" or the end of a String. opw-5038334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The cash basis General Ledger now correctly combines related payment lines before showing additional results. This prevents users from hitting an error when using Load more on accounts with many invoice payments, making the report more reliable.
Original PR description
**Steps to reproduce:**: - Install the module "account_reports_cash_basis" - Create a new account - Create an invoice with a line in the newly created account - Create a number of payments on the…
**Steps to reproduce:**: - Install the module "account_reports_cash_basis" - Create a new account - Create an invoice with a line in the newly created account - Create a number of payments on the invoice - Go to general ledger, and set method to cash basis - Set limit to a value less than the number of payments - Open the account on the general ledger, and click on load more **Issue:** After clicking on 'Load more', we get a traceback due to duplicate lines **Cause:** The same aml can return multiple results when using "account_reports_cash_basis" module. While this has been taken into consideration for each batch of lines loaded into the report (we won't get the same line referenced two times in the same batch, since they are grouped together), if we load a new batch by clicking "Load More", we can potentially get a line that was referenced in the first batch, and we get an error for having two lines in the report referencing the same thing. **Solution:** We add a add a GROUPBY statement in the query of _get_aml_values() This will add up all the cash basis lines in the query itself. opw-4635115 Forward-Port-Of: odoo/enterprise#86817