Daily updates from Odoo
Tuesday, November 11, 2025
8 changes · 19.0
Enhancements to existing features
This update speeds up how Odoo calculates amounts on account moves, especially when processing records with many lines. It reduces waiting time, memory usage, and database load, which should make large reconciliation and accounting operations noticeably faster.
Original PR description
Currently performance on `_compute_amount()` is bottlenecked by `__get__()` calls on fields on `line_ids`. We tackle this bottleneck by warming the cache with `fetch()` Benchmark on reconciling 2 account moves with ~70k lines each | |Total Time|Allocated Memory|Queries| |----------|----------|----------------|-------| |Before |43.23s |2GB |993 | |After |18.60s |1GB |693 | opw-5098543 Forward-Port-Of: odoo/odoo#234656
Resolved issues and error corrections
This fix prevents duplicate withholding taxes from being created when the Argentina withholding demo data is installed. It keeps the tax list clean and avoids confusing duplicate entries for users configuring accounting settings.
Original PR description
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo…
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo data. 2. Take position in "(AR) Responsable Inscripto" company. 3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 4. Delete the filter "Sale or Purchase". 5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"]. 6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). **Current behavior before PR**: Duplicated taxes are created when demo data is installed. <img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" /> **Desired behavior after PR is merged**: No duplicated taxes are created when demo data is installed. _Task latam side_: 1360. _Task Adhoc side_: 57627. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226992
This change turns off IndexedDB during a subset of point of sale automated tests so the full test suite does not create an excessive number of browser databases. It helps keep test runs faster and more reliable, while dedicated tests still cover IndexedDB separately.
Original PR description
Disable IndexedDB in Hoot tests to avoid creating to much IndexedDB databases when running the full test suite. IndexedDB is still tested in dedicated tours. Forward-Port-Of: odoo/odoo#234701
This change prevents a crash that could happen when removing the Invoicing app after using the U.S. accounting localization. It ensures related setup data is cleaned up correctly during uninstall, so users can remove modules without hitting an error.
Original PR description
The system will crash when user tries to uninstall the `invoicing` module. **Steps to produce:** - Install `Accounting` module without demo data. - Go to Accounting > Configuration > Settings > Set…
The system will crash when user tries to uninstall the `invoicing` module. **Steps to produce:** - Install `Accounting` module without demo data. - Go to Accounting > Configuration > Settings > Set fiscal localization as `United States`. - Go to `Apps > Accounting > uninstall`. - Now try to uninstall `Invoicing` module. **Error:** `KeyError: 'account.asset'` **Cause:** - [Here] in `l10n_us_account` module, we define data of `account.asset` model. - When we uninstall the `accountant` module, it also uninstalls `account_asset` module and also uninstall the `account.asset` model. - the asset data loaded by `l10n_us_account` was incorrectly owned by the `account` module. - When we later uninstall the `account` module, it finds `account.asset` data and tries to delete it. **Solution:** - Added uninstall_hook in l10n_us_account to unlink the account.asset record. [Here]https://github.com/odoo/odoo/blob/e1dd3852b118eacc8d77e9e3d8c7769195c6edb1/addons/l10n_us_account/data/template/account.asset-us.csv#L2-L8 **sentry-6938852090** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents errors when uninstalling the Mail module by making sure it only looks for activity records if the related database columns still exist. This helps module removal and later reinstallation complete cleanly, avoiding database errors that could block the process.
Original PR description
When uninstalling module mail, an override of `unlink()` deletes the activities of the records being deleted. However, this override crashes whenever columns of `mail.activity` have been dropped already. As a consequence, it may prevent the deletion of the field `mail_message_id` of model `mail.tracking.value`, and its table, too. And this causes the reinstallation of module mail to log error: ``` column "mail_message_id" of relation "mail_tracking_value" contains null values ``` See https://runbot.odoo.com/odoo/runbot.build.error/233618 for the cases where it failed. The fix consists in checking whether the columns of `mail.activity` still exist before searching for activities. Forward-Port-Of: odoo/odoo#235083
When a product is manufactured from a sales order using the make-to-order flow, the resulting manufacturing order will now correctly show which sales order line created it. This improves traceability and makes it easier for business users to follow the origin of production orders.
Original PR description
[FIX] sale_mrp: set sale_line_id on manufacturing order during MTO route Problem: Manufacturing Orders should contain information about their origin, but during an MTO route, sale_line_id remains unset after the MO is created when the Sales Order is confirmed. Solution: While preparing the values for the MO (`_prepare_mo_vals`), we will assign the `sale_line_id` based on the MO's move, which has the origin sale_line_id during the MTO route. Steps to replicate on Runbot 18: - Product with MTO and Manufacture routes - BoM with at least one component 1. Create a Sales Order for the product and confirm 2. Navigate to the MO via the smart button 3. Check the field sale_line_id with the inspector, note it is False. opw-5257401
This change prevents website assets from being accidentally switched off when modules are updated. It helps ensure older snippet styles and page content continue to display correctly, while unused assets are still cleaned up later by the system.
Original PR description
Before this commit when a module was updated all ir.asset records were reset to their defined `active` state, if defined. This causes assets related to old snippet versions to be made inactive even…
Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.
It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].
This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).
Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
def _load_records_write(self, values):
values.pop('active', None)
super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.
[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
task-2963840
(Follow-up of https://github.com/odoo/upgrade/pull/3829)
Forward-Port-Of: odoo/odoo#233899
Forward-Port-Of: odoo/odoo#104836This change updates how website appointment pages load shared resources so they use the newer asset format. It helps keep the feature compatible with the latest platform standards and reduces the risk of future maintenance issues.
Original PR description
See https://github.com/odoo/odoo/pull/104836 task-2963840 Forward-Port-Of: odoo/enterprise#98530 Forward-Port-Of: odoo/enterprise#35153