Tuesday, November 11, 2025
5 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 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#104836