Thursday, September 4, 2025
16 changes · 18.0
Enhancements to existing features
Point of Sale now avoids loading large sets of product attribute values during startup when they are not immediately needed. This reduces unnecessary data loading and improves performance for businesses with products that have many variants or options.
Original PR description
Before this commit, when loading PoS, all product template attribute value (ptav) IDs linked to a product attribute were loaded. This caused performance issues when attributes had a large number of values, even though they were not needed at that stage. With this commit, the values are no longer preloaded, since the reverse fields in ptav and ptal are fetched when needed, ensuring they can still be linked correctly without degrading performance. opw-5006818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Imported supplier bills now group invoice lines by tax, so accountants can quickly see which amounts correspond to each tax rate instead of reviewing every individual line. This makes bill review faster and easier while preserving the tax information needed for accounting checks.
Original PR description
[IMP] account_edi_ubl_cii: group imported invoice lines by tax Most of the time, an accountant that imports a bill don't need to see every line. What's useful to him is to see what amount is linked to what tax. task-5047859
Stock replenishment rule lookups are now processed in batches instead of one by one. This reduces delays in workflows that evaluate many products and locations, such as replenishment planning, making larger operations noticeably faster without changing user-facing behavior.
Original PR description
Currrently `product.product._get_rules_from_location` can become a performance bottleneck when it's called multiple times. Because the method finds a candidate stock.rule then call itself recursively…
Currrently `product.product._get_rules_from_location` can become a performance bottleneck when it's called multiple times. Because the method finds a candidate stock.rule then call itself recursively with stock.rule.location_src_id, it's difficult to properly batch. In this commit we introduce two methods, `product.product._get_rules_for_combinations` and `procurement.group._get_rules_for_combinations`. The second one is a batched version of `get_rule`. The idea is that given a list of (products, locations, warehouses), the method will call `search_rules_for_warehouses` only once and then distribute the fetched stock.rule to the correct `(product, location, warehouse)` triplet by building a dictionary. This is then used by `product.product.get_rules_for_combinations` which takes a list of `(products, locations)` pairs and build a recordset of stock.rules for each one. The way to use this workflow is the following: - The calling code creates the list of (product_id, location_id) it needs. E.g. `[(o.product_id, o.location_id) for o in orderpoints)]` - A single call to `product.product._get_rules_for_combinations` - stock.rules are then extracted by the calling code using the resulting dictionary. Assuming the worst case, the current code does (n+k) calls to both `product.product._get_rules_from_location` and `procurement.group._get_rule`, with n being `len([(r.product_id, r.location_id) for r in records])` and k the total number of recursive calls in `product.product._get_rules_from_location` After this commit, the worst case will be h calls to both methods, with h being the height of `product.product._get_rules_for_combinations` recursive call tree. #### speedup Current iterative version product._get_rules_from_location | Total loops count | Exec Time | |:-------------------:|:------------:| | 10 | 50ms | | 50 | 62ms | | 500 | 567ms | | 7 441 | 5.6s | Benchmark of product._get_rules_for_combinations | combinations Nb | Exec Time | |:-------------------:|:-----------:| | 10 | 24 ms | | 50 | 23ms | | 500 | 93ms | | 7 441 | 1.23s | Average speedup calling both method from a shell: 2.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app now shows files in their default order based on when they were created instead of when they were last changed. This makes document lists and the trash more stable, so small edits like adding tags or upgrade-related updates no longer unexpectedly move items around.
Original PR description
As the write_date can be reset by very small changes like adding a tag, updating its name and also during some upgrade, we set the default ordering to create_date. We do similarly for the trash. Task-5025453
The Master Production Schedule has been optimized to load and update much faster, especially for companies with many schedules and complex bills of materials. This reduces wait times when opening the MPS or changing order quantities, helping planning teams work more efficiently.
Original PR description
Multiple optimizations for the MPS. Utilizes new method `product.product._get_rules_for_combinations`. Memoize results in dictionaries and pass them to method via context/params. Add BFS preprocessing to `_get_indirect_demand_tree` to get boms in batches instead of one component at a time. #### speedup In a database with 1087 schedules and complicated bom structure, Opening the MPS `get_mps_view_state`: - 9.23s -> 4.97s Changing To Order qty in MPS `get_production_schedule_view_state`: - 25s -> 6s
UrbanPiper connection errors now show the actual message returned by the service instead of a generic technical error. This helps teams quickly understand failures, such as duplicate store references, and resolve setup or synchronization issues faster.
Original PR description
Before this commit: --- - HTTP errors from UrbanPiper API only showed the generic Python exception. - It was difficult to identify the actual cause (e.g., duplicate store ref_id). After this commit: --- - HTTP error handling now extracts the `message` from the API JSON response. - The displayed/logged error clearly reflects the real cause of the failure. task-5026169
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