Daily updates from Odoo
Friday, September 19, 2025
8 changes · saas-18.4
Resolved issues and error corrections
This fix changes how default supplier taxes are applied so large product databases can be updated without running out of memory. It helps accounting setup and migrations complete reliably for companies with many products sharing the same supplier tax.
Original PR description
As I mentioned in the query below, multiple grouped product.template records with the same supplier_taxes_id are being modified with the default purchase tax (account_purchase_tax_id),which leads to…
As I mentioned in the query below, multiple grouped product.template records with the same supplier_taxes_id are being modified with the default purchase tax (account_purchase_tax_id),which leads to a memory error. To prevent this, I have used an INSERT query.
```sql
SELECT tax_id, COUNT(*) AS product_count
FROM product_supplier_taxes_rel
GROUP BY tax_id
ORDER BY product_count DESC;
tax_id | product_count
--------+---------------
15 | 1262126
156 | 343332
114 | 36363
47 | 10132
23 | 202
546 | 11
474 | 5
782 | 2
666 | 2
1188 | 2
1318 | 1
3 | 1
(12 rows)
```
- Traceback
```python
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1314, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 515, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/17.0/addons/l10n_ch/migrations/11.3/end-migrate.py", line 8, in migrate
env["account.chart.template"].try_loading("ch", company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/point_of_sale/models/chart_template.py", line 22, in _load
result = super()._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 214, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 10, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/17.0/addons/stock_account/models/account_chart_template.py", line 12, in _post_load_data
super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 669, in _post_load_data
sudoed_products_purchase._force_default_purchase_tax(company)
File "/home/odoo/src/odoo/17.0/addons/account/models/product.py", line 130, in _force_default_purchase_tax
product_grouped_by_tax.supplier_taxes_id += default_supplier_taxes
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1322, in __set__
records.write({self.name: write_value})
File "/home/odoo/src/odoo/17.0/addons/website_sale/models/product_template.py", line 176, in write
return super().write(vals)
File "/home/odoo/src/odoo/17.0/addons/rating/models/rating_mixin.py", line 100, in write
result = super(RatingMixin, self).write(values)
File "/home/odoo/src/odoo/17.0/addons/stock_account/models/product.py", line 55, in write
res = super(ProductTemplate, self).write(vals)
File "/home/odoo/src/odoo/17.0/addons/mrp/models/product.py", line 74, in write
return super().write(values)
File "/home/odoo/src/odoo/17.0/addons/stock/models/product.py", line 921, in write
return super(ProductTemplate, self).write(vals)
File "/home/odoo/src/odoo/17.0/addons/product/models/product_template.py", line 502, in write
res = super(ProductTemplate, self).write(vals)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 311, in write
return super(MailThread, self).write(values)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_activity_mixin.py", line 250, in write
return super(MailActivityMixin, self).write(vals)
File "/home/odoo/src/odoo/17.0/addons/website/models/mixins.py", line 218, in write
return super(WebsitePublishedMixin, self).write(values)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4444, in write
field.write(self, value)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4337, in write
self.write_batch([(records, value)])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4358, in write_batch
self.write_real(records_commands_list, create)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 4957, in write_real
y_to_xs[y].add(x)
File "/home/odoo/src/odoo/17.0/odoo/tools/misc.py", line 1136, in add
self._map[elem] = None
MemoryError
```
opw - 4544050
upg - 2459515
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227532
Forward-Port-Of: odoo/odoo#204931The calendar year view now responds properly when the browser window is resized. This prevents display issues and helps users keep a clear yearly schedule view across different screen sizes.
Original PR description
FullCalendar already applies a debounce on the `windowResize` handler. Thus, doing it again in our renderer is a duplicated effort. Also, in the Year calendar renderer, the debounced version of the handler is initialized after the FullCalendar instances (one for each month) are created... which prevents it from being run at all. This commit fixes and cleans this up by directly passing our handler to FullCalendar, letting him do the rest. task-4809668 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227725 Forward-Port-Of: odoo/odoo#227458
This fix gives the test user the required Sales access so Mexican localization tests can create sales orders successfully. It does not change business behavior, but helps keep automated checks reliable for this localization.
Original PR description
The tests `test_global_discount` and `test_down_payment` in `l10n_mx_edi_sale` were failing with:
AccessError: You are not allowed to create 'Sales Order' (sale.order) records.
This happened because `mx_external_setup` runs with a user that does not belong to any Sales group. Both tests explicitly create Sale Orders and advance payment wizards, which require Sales ACLs.
This change ensures the test user has the `sales_team.group_sale_salesman` group in `setUpClass`, so Sales Orders can be created normally. No business logic is modified, only test stabilization for the MX localization.
[RB-232559](https://runbot.odoo.com/odoo/error/232559)
Forward-Port-Of: odoo/enterprise#94911This update brings the embedded spreadsheet component to its latest version and fixes several issues affecting spreadsheet calculations. Users should see clearer formula error messages and more reliable pivot table calculated measures, especially when working with totals.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c7e71ac07 [REL] 18.4.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c7e71ac07 [REL] 18.4.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/716824c3d [FIX] functions: wrong error message for `SORT` [Task: 5085267](https://www.odoo.com/odoo/2328/tasks/5085267) https://github.com/odoo/o-spreadsheet/commit/7cd1c8af8 [FIX] helpers: preserve sparse(empty) elements in removeIndexesFromArray [Task: 4977932](https://www.odoo.com/odoo/2328/tasks/4977932) https://github.com/odoo/o-spreadsheet/commit/cbf814c77 [FIX] package: add swc binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e7ecca4fc [FIX] pivot: calculated measure from totals [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/47870c124 [FIX] pivot: add aggregator to calculated measure id [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The Indian GSTR-3B report now includes purchase credit notes, receipts, and other purchase records correctly. This helps businesses see more accurate tax reporting data and avoids purchase-related amounts being shown through the POS report, where they do not belong.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#95079 Forward-Port-Of: odoo/enterprise#94582
Field service tasks created from templates now correctly keep the template's "Under Warranty" setting. This ensures warranty-related service work is identified accurately from the start, reducing manual correction and billing or service handling mistakes.
Original PR description
**Steps to reproduce:**
- Install industry_fsm_sale
- Create a task template with "Under Warranty" enabled
- Create a task from that template
**Issue:**
The created task does not carry over the "Under Warranty" value from the task template.
**Cause:**
The `under_warranty` field has `copy=False`, so the value is not transferred.
**Fix:**
Updated the copy method to check for `copy_from_template` in the context. If the task template has "Under Warranty" enabled, the field is explicitly set on the new task.
task: 5083386
Forward-Port-Of: odoo/enterprise#94924This change rolls back recent manufacturing and inventory accounting updates that attempted to correct valuation during unbuild operations but introduced additional accounting inconsistencies and errors. The revert restores the prior behavior while the team prepares a cleaner solution, reducing the risk of new regressions in stock valuation and purchase/manufacturing accounting.
Original PR description
This commit reverts [1], [2], [3], and [4]. (It actually results in minimal changes since those commits were already removing parts of each other.) Issue before those commits: 1. Setup a auto-fifo…
This commit reverts [1], [2], [3], and [4]. (It actually results in minimal changes since those commits were already removing parts of each other.) Issue before those commits: 1. Setup a auto-fifo category and two storable products (a component and a finished product) 2. Receive one compo at 10, then one at 25 3. Produce two MO with one finished product 4. Unbuild the second one Error: - For the component, we just use the value of the consumed components: IN 1 @ 25 - For the finished product, we process it as a classic out. Reminder, we are in FIFO: OUT 1 @ 10 As a result, thanks to the unbuild, we have created - A over-valuation of the stock (+15) - An outstanding balance of the "Cost of Production" This is why [1] has been merged. However, it brought some other issues, cf [2], [3] and [4]. Unfortunately, it still has some issues - After the above use case, the difference between the debit and the credit of the stock valuation account is no longer the sum of the remaining values of the layers - Adding some landed costs on MOs will lead to a traceback when undbuilding - The over-valuation of the stock (that was already present before [1], cf above) is still present Following some discussions with R&D and the product owners, we have decided to start over from scratch, which means: - Revert all commits - Try another approach (if so, the new PR will be linked to the PR related with this commit) [2], [3], and [4] are partially reverted: the tests can remain, as they were only failing due to a sequence of changes. [1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 [2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c [3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47 [4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0 OPW-5036574 Forward-Port-Of: odoo/odoo#226380 Forward-Port-Of: odoo/odoo#225728
This fix prevents crashes when the system loads unusual record combinations, such as temporary records mixed with saved records or records with an empty identifier. It improves overall platform stability and keeps behavior consistent across core data operations.
Original PR description
This commit addresses two corner cases that cause `fetch()` to crash: Mixing new and real records: - Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`. - Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM. Using `False` as a record id: - Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called. - Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error. Forward-Port-Of: odoo/odoo#227447