Daily updates from Odoo
Friday, November 21, 2025
8 changes · 19.0
Enhancements to existing features
This change reduces the time needed to validate stock movements by avoiding repeated calculations of the same location data. It improves performance for movements that trigger putaway checks, making large inventory operations noticeably faster.
Original PR description
Previously when validating a movement with a location that is used in a rule, move_dest_ids was set which led to it going to check the putaway strategy. The bottleneck was the computation of the computed field child_internal_location_ids which is the same across all smls. This PR utilizes the fact that the smls in the same stock_move would have the same destination location and by proxy the same child_internal_location_ids Speed up: 1000 stock move lines: Before: 2 mins After: 1 mins --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233467 Forward-Port-Of: odoo/odoo#210142
This change simplifies how Odoo automatically converts database fields during upgrades. It avoids unnecessary recalculation work and keeps database constraints intact, which makes upgrades faster and reduces the risk of unexpected side effects.
Original PR description
The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle…
The auto column conversion should be limited to simple and intuitive use cases. It shouldn't trigger the slow ORM recomputation if the field is computed. We always expect an upgrade script to handle more complex use cases.
This commit introduces two changes:
### 1. Removal of `drop_not_null` during auto column conversion
Before https://github.com/odoo/odoo/commit/50767ef90eadeca2ed05b9400238af8bdbe77fb3 We dropped the not_null constraint because the original column would be renamed. After that commit, we actually don't need to drop the not_null constraint since the `convert_column` will neither convert a not-null value to `null` nor convert 'null' to a not-null value. Keeping the not_null constraint shouldn't block the column convert.
### 2. Removal of `column.clear()`
When a computed/related Float field is changed from `digits=None` to `digits='xxx'`, the `column.clear()` will trigger ORM recomputation during upgrade which is useless since `double precision` to `numeric` is lossless. The recomputation in ORM is slow and should be avoided. If the rerounding is really needed, a sql script is required for upgrade or installation.
The `column.clear()` was originally introduced to avoid `Missing not-null constraint` warnings in specific scenarios:
Case 1 (Upgrade Warning): from saas-18.4 to 19.0
old database: Selection field `l10n_be.export.sdworx.leaves.wizard.reference_year` upgrade: pre-migrate `util.rename_model(cr, "l10n_be.export.sdworx.leaves.wizard", "l10n.be.hr.payroll.export.sdworx")` new database: Integer field `l10n.be.hr.payroll.export.sdworx.reference_year` The column value which was a required stringified integer is auto-converted to an integer.
Case 2 (Installation Warning):
In pos_urban_piper, the required field `pos.config.name` is overridden from `translate=False` to `translate=True`. The column value which was a required text is auto-converted to `'{"en_US": "text"}'::jsonb`
The not_null constraint was previously lost by the `sql.drop_not_null` in `update_db_column` and is not restored by `update_db_notnull` because of the inconsistency between the variable `column['is_nullable']` and the actual not_null constraint in the database.
Thanks to change 1, we will no longer lose the not_null constraint in `update_db_column`. The constraint can be kept even without `column.clear()`.
By removing the `column.clear()`, we also revert the meaning of the `column` variable, which is the column's configuration (dict) before `update_db` if it exists, or `None`
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#236299Automatic reconciliation will now pick the most suitable earlier or same-day entry when there are several possible matches instead of stopping without action. This should reduce manual follow-up and make bank statement processing smoother.
Original PR description
When having multiple candidates with the try_auto_reconcile we used to do nothing since there was a doubt. This commit will slightly change that by selecting the move line with the closer prior or equal date. task-5212876
This update makes the manufacturing work order finish process much faster by avoiding repeated calculations and duplicate database updates. As a result, large batches of work orders complete more reliably and with far less memory usage.
Original PR description
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However,…
- The `button_finish` method contained a variable intended to filter out moves whose `operation_id` matched the `operation_id` of the entire recordset of work orders passed to the function. However, this filtering was performed inside a loop iterating over all work orders, even though the result of the filtration did not depend on any single work order. Before this commit: - The filtration was executed repeatedly for each work order, despite being deterministic. - This unnecessary repetition caused performance degradation and multiple redundant updates to the `picked` field of the same moves, resulting in fake or redundant database writes. After this commit: - The filtration logic has been moved outside the iteration, ensuring that the update to the moves is performed only once, improving overall performance and preventing redundant updates. - The `end_all` method is now executed on the entire recordset of work orders at once, instead of being called individually for each iteration. The benchmark below is done on a recordset of workorders of size **500** and the number of moves returned from the filter were **100**. It set the picked field to be **True** for every workorder in the recordset, potentially triggering recomputation of some of the fields and doing more redundant SQL queries. opw-5092636 ### Benchmark Results | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **Memory Error** | **After this Commit** | **22 seconds** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235405 Forward-Port-Of: odoo/odoo#233102
The Indian tax reports were updated to remove a section that is no longer needed. This also keeps report output cleaner by hiding lines when they have no value, reducing unnecessary clutter for users reviewing the reports.
Original PR description
Since the `purchase_b2c_regular` GSTR section is no longer required, this commit updates the related domain logic and hides the corresponding report lines when their value is 0. Related PR: https://github.com/odoo/odoo/pull/236241
The Partner VAT Listing now excludes exempt transactions that were previously shown as 0% taxes in some cases. This brings the report in line with Belgian VAT rules by distinguishing exempt operations from taxable ones, even when the tax rate is zero.
Original PR description
Currently, the behavior is wrong and 0% taxes appear in the report (if the cumulative base for a partner is > 250) A distinction needs to be done here. The operations are taxable (even at a zero rate) or exempt. We shall rely on the Tax Category Code (E = Exempt) When a tax belongs to E, it cannot appear in the Partner VAT Listing. It is exempt from taxation. It does not open the right to deduction of vat on purchases. task-5269970
The GST purchase report no longer includes the "purchase_b2c_regular" section because unregistered vendors cannot use regular GST taxes. This simplifies the report and keeps the remaining categories aligned with how these transactions actually work, including overseas cases covered elsewhere.
Original PR description
Unregistered vendors cannot apply regular GST taxes, making the `purchase_b2c_regular` GSTR section unnecessary. Additionally, `purchase_cdnur_regular` will also cover only overseas cases. With this commit, the `purchase_b2c_regular` section will be removed. Relateed PR: https://github.com/odoo/enterprise/pull/99777
This change makes sign template fields easier to extend or adapt in future updates. It helps maintainers and partners add or adjust fields with less risk of breaking existing behavior, improving flexibility for custom setups.
Original PR description
Introduced a dedicated _getTemplateFields() method to make easier to override or extend the fields in patches. Forward-Port-Of: odoo/enterprise#95722