Monday, November 10, 2025
5 changes · 18.0
Enhancements to existing features
The bank statement validation process was optimized to run faster on large databases. This reduces waiting time for users and lowers database load, helping the system stay more responsive.
Original PR description
Description ----------- Avoid self-join of `account_bank_statement` that is done with a `Nested Loop` due to the `LATERAL`. Even if correlated, it requires two separate accesses to its index. Replaces it with a window function + `LAG` partitioned by the `journal_id`. This leads to a simpler plan (lower cost) and working in-memory instead of accessing disk pages (lower IO contention). Benchmark --------- On a database with 46k `account_bank_statement`, calling `_get_invalid_statement_ids` for all statements took: | [Before](https://explain.dalibo.com/plan/7605a4ddc42afbcf) | [After](https://explain.dalibo.com/plan/88d6ac1gee37aha3) | Speed-up | |--------|-------|----------| | 146ms | 72ms | 2x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232980
Resolved issues and error corrections
This update fixes a spelling mistake in the Website Sale module, changing an incorrect word to the intended one. It improves the clarity and professionalism of the customer-facing text without affecting how the feature works.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes a typo that was found in website_sale module. There is a mistake in writing "you" --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds automated tests for a sales margin scenario to make sure purchase price is recalculated correctly when a canceled order is reset, then the pricelist currency is changed. It helps prevent pricing errors for products with automated costing methods and improves confidence in future changes.
Original PR description
Description of the issue/feature this PR addresses: Test-only PR to verify `purchase_price` recomputation behavior when changing pricelist currency after order cancellation (per reviewer feedback on https://github.com/odoo/odoo/pull/232553). Current behavior before PR: No test coverage for this scenario. Desired behavior after PR is merged: Test validates correct currency conversion of `purchase_price` for AVCO/FIFO products after cancel → draft → pricelist change workflow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a candidate’s name is changed, any existing follow-up activities now automatically reflect the updated name. This keeps records consistent and avoids confusion for recruiters viewing older tasks.
Original PR description
Issue: When updating an hr recruitement candidate name (stored in hr_applicant after 18.2) the name change is not updated in the name of previously created activities. Cause: The field res_name in mail.activity is computed and stored only at creation of an activity. Solution: Retrigger the compute of an activity when updating a candidates name. Task-4988342
This update adjusts an automated purchase test so it works correctly with PostgreSQL 18. It keeps the test focused on the real business behavior while avoiding a database-specific error name change that caused unnecessary test failures.
Original PR description
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.