Odoo Changelog — 2026-07-28

Tuesday, July 28, 2026

37 changes · saas-19.2

Improvements(1)

Enhancements to existing features

[IMP] auth_signup: implement well-known change-password endpoint

Coresaas-19.2auth_signup

Original PR description

Password managers and browsers rely on the standardized `/.well-known/change-password` URL to automatically locate a site's password change form, instead of relying on unreliable heuristics to detect it inside the page.

Without this endpoint, users depending on password manager integrations (Chrome, Safari, 1Password, Bitwarden, etc) have no reliable way to be redirected to the actual reset form, resulting in a degraded UX and inconsistent behavior across browsers.

This implements the Change Password URL specification by exposing a public route that redirects to `/web/reset_password`.

Reference: https://wicg.github.io/change-password-url/

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#277575

Bug Fixes(34)

Resolved issues and error corrections

[FIX] account_reports: add a test for CTA table

PR #124871

Enterprisesaas-19.2account_reports

Adds a validation test to ensure reports calculate currency translation adjustments correctly when the company's domestic currency rate changes during the year. This helps prevent overstated or understated financial reporting figures in multi-currency scenarios.

Original PR description

Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD…

Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency.

Scenario 2: fluctuating domestic (USD) rate
 USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31
 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1

 Correct conversion factors (= USD_rate / EUR_rate):
  Jan 1 – Jun 30 (182 days): 1/2 = 0.50
  Jul 1 – Dec 31 (184 days): 3/4 = 0.75

 Current rate at 2020-12-31:      3/4 = 0.75
 Correct average rate:            (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568
 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295

 Historical equity rates (correct vs previously bugged):
  Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50  → 40 * 0.50 = 20 vs 40 * 1.50 = 60
  Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75  → 60 * 0.75 = 45 (same by coincidence)

task-5953104

Forward-Port-Of: odoo/enterprise#123055

Other(2)

Miscellaneous changes

[PERF] hr_holidays_attendance: `hr_leave_attendance_report`

PR #278690

Coresaas-19.2hr_holidays_attendance

Original PR description

On a production-sized database the `hr.leave.attendance.report` SQL view took over three hours to run. This caused a significant load on the upgrade platform when processing databases that have a…

On a production-sized database the `hr.leave.attendance.report` SQL
view took over three hours to run. This caused a significant load on the
upgrade platform when processing databases that have a large number of
`hr.employee` records. Specifically, when running `test_mock_crawl` and
mocking the `Attendances > Reporting > Time Off Ledger` menu.

PostgreSQL mis-estimated the row counts produced by the view:

- The public-holiday check combined an `OR` with a function-wrapped
  `BETWEEN` (`... AT TIME ZONE ... ::date`), which the planner cannot
  estimate; it predicted ~1 surviving row (actual: 29.4M) and chose
  nested loops that re-aggregated whole tables once per output row.
- The attendance sub-query aggregated the entire `hr_attendance`
  table with no date bound, and was re-executed per output row.
- The working schedule was resolved with a per-(employee, day)
  `LIMIT 1` lookup into `hr_version` (29.4M index probes).

Rewrite the view as a set of CTEs: every heavy table is scanned once,
joins use plain equality keys (hash-joinable), public holidays are
pre-expanded so their exclusion stays an anti-join, the attendance
aggregate is bounded to the report window, and hr_version is resolved
by expanding each version over the days it covers. None of the CTEs
are explicitly materialized: left to its own heuristic, PostgreSQL
inlines a CTE referenced only once as a plain subquery and materializes
the ones referenced more than once, which benchmarked faster than
forcing materialization everywhere.

This rewrites the body of the SQL view only: no schema change, no new
field, no index, no migration. The report output is unchanged.

Measured with EXPLAIN (ANALYZE, BUFFERS) on the same database:

  | metric         | before        | after    | factor |
  |----------------|---------------|----------|--------|
  | execution time | 11 852 235 ms | 1 834 ms | ~6500x |
  | buffer hits    | 115 311 556   | 71 890   | ~1600x |

upg-4288902

Forward-Port-Of: odoo/odoo#266108

Password managers and browsers rely on the standardized `/.well-known/change-password` URL to automatically locate a site's password change form, instead of relying on unreliable heuristics to detect it inside the page. Without this endpoint, users depending on password manager integrations (Chrome, Safari, 1Password, Bitwarden, etc) have no reliable way to be redirected to the actual reset form, resulting in a degraded UX and inconsistent behavior across browsers. This implements the Change Password URL specification by exposing a public route that redirects to `/web/reset_password`. Reference: https://wicg.github.io/change-password-url/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277575

Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1 Correct conversion factors (= USD_rate / EUR_rate): Jan 1 – Jun 30 (182 days): 1/2 = 0.50 Jul 1 – Dec 31 (184 days): 3/4 = 0.75 Current rate at 2020-12-31: 3/4 = 0.75 Correct average rate: (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295 Historical equity rates (correct vs previously bugged): Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50 → 40 * 0.50 = 20 vs 40 * 1.50 = 60 Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75 → 60 * 0.75 = 45 (same by coincidence) task-5953104 Forward-Port-Of: odoo/enterprise#123055

On a production-sized database the `hr.leave.attendance.report` SQL view took over three hours to run. This caused a significant load on the upgrade platform when processing databases that have a large number of `hr.employee` records. Specifically, when running `test_mock_crawl` and mocking the `Attendances > Reporting > Time Off Ledger` menu. PostgreSQL mis-estimated the row counts produced by the view: - The public-holiday check combined an `OR` with a function-wrapped `BETWEEN` (`... AT TIME ZONE ... ::date`), which the planner cannot estimate; it predicted ~1 surviving row (actual: 29.4M) and chose nested loops that re-aggregated whole tables once per output row. - The attendance sub-query aggregated the entire `hr_attendance` table with no date bound, and was re-executed per output row. - The working schedule was resolved with a per-(employee, day) `LIMIT 1` lookup into `hr_version` (29.4M index probes). Rewrite the view as a set of CTEs: every heavy table is scanned once, joins use plain equality keys (hash-joinable), public holidays are pre-expanded so their exclusion stays an anti-join, the attendance aggregate is bounded to the report window, and hr_version is resolved by expanding each version over the days it covers. None of the CTEs are explicitly materialized: left to its own heuristic, PostgreSQL inlines a CTE referenced only once as a plain subquery and materializes the ones referenced more than once, which benchmarked faster than forcing materialization everywhere. This rewrites the body of the SQL view only: no schema change, no new field, no index, no migration. The report output is unchanged. Measured with EXPLAIN (ANALYZE, BUFFERS) on the same database: | metric | before | after | factor | |----------------|---------------|----------|--------| | execution time | 11 852 235 ms | 1 834 ms | ~6500x | | buffer hits | 115 311 556 | 71 890 | ~1600x | upg-4288902 Forward-Port-Of: odoo/odoo#266108

When a POS order is invoiced after its session has been closed, `_create_misc_reversal_move` builds a misc entry that reverses the portion of the closing entry corresponding to that order. It does so by negating `balance` and `amount_currency` on every prepared line, but leaves `tax_base_amount` on tax lines untouched. As a result the reversal move ends up with tax lines whose `balance` sign is flipped relative to the source order while `tax_base_amount` keeps the source sign, breaking the invariant `sign(balance) == sign(tax_base_amount)` that holds for every other correctly-generated tax line in the system. Downstream, any report reading `tax_base_amount` directly (Audit view from the Tax Report, Journal Items XLSX export, custom exports) shows a base amount signed for the wrong direction alongside a debit/credit of the opposite sign, which is confusing and, for tax returns computed from `tax_base_amount`, incorrect. Negate `tax_base_amount` alongside `balance` and `amount_currency` so the reversal move stays internally consistent. opw-5975658 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#276534

Description of the issue/feature this PR addresses: A cash rounding line resolves its company-dependent profit/loss account against the active company instead of the invoice's own company, which breaks multi-company invoicing whenever the invoice's company differs from the active one. Current behavior before PR: - Enable Multi-Companies in the settings. - Create a second company (Company B). - Open Accounting > Configuration > Cash Roundings. - Create a cash rounding with strategy "Add a rounding line" and precision 1.00. - Make Company A the active company in the company switcher. - Set the cash rounding's profit and loss accounts to Company A accounts. - Switch the active company to Company B. - Set the cash rounding's profit and loss accounts to Company B accounts. - Make Company A the active company again, keeping both companies active. - Create a customer invoice for Company B. - Add one invoice line whose total is not a multiple of the rounding precision. - Set the invoice's cash rounding to the one above. > Adding the rounding line raises a cross-company UserError: the company-dependent account is resolved against Company A while the invoice belongs to Company B. Desired behavior after PR is merged: The rounding line resolves the company-dependent profit/loss account against the invoice's own company, so the rounding line always uses that company's account and no cross-company error is raised. Covered by the added test TestAccountMoveCashRoundingMultiCompany. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278401 Forward-Port-Of: odoo/odoo#273410

[FIX] html_builder: fix job location editing on website Scenario: 1) Head over to website 2) Go to any specific job page 3) Open editor 4) Try changing job location 5) Hit save Result: The changes aren't saved or propagated into the backend. Expectation: Users should be able to edit job locations via the editor on website and have those changes reflect on the site and job record. Cause: How elements were marked as savable was changed [in this IMP][1] to rely on `o_savable` rather than the savable selectors resource. As a result, elements which had the `o_not_editable` class, such as job location, did not have `o_savable` added to them. These elements were excluded from the builder's dirty-tracking for save. Therefore, editing the location didn't mark the element as changed and saving to drop the update. Fix: Remove `o_not_editable` from the location element on plugin setup so the field is now editable and savable through the builder option. This surfaced a second issue: when the location was set to "Remote", the element's content could be directly editable inline. Saving it that way disconnected the content from the job location field. This was fixed by adjusting the selector that determines when a many2one's content is editable inline. The result is the "Remote" case is handled consistently as changing to any other location. [1]: https://github.com/odoo/odoo/commit/f3c119dd034b4c3df9f392b0cdc66a1141662c25 Task-6311200 Forward-Port-Of: odoo/odoo#274731

#### Issue: When creating a reordering rule for a shared manufactured product in a multi-company database, saving the rule may raise an `AccessError` on `mrp.bom`. The orderpoint is still created, but the user sees a record-rule error if the product also has BoMs in companies that are not currently active. #### Example: A product is shared across multiple companies, and each company has its own BoM for that product. In the reproduced case, the active company has the correct variant BoM. However, the orderpoint computation first checks the broader product-template BoM relation, which may include BoMs from the other companies. As a result, Odoo can try to access a BoM from another company while the user is only working in the active company, causing an access error. #### Steps to reproduce: Use a multi-company database with MRP enabled. Create or use a shared product available to multiple companies. Create BoMs for that product in more than one company. Set the active company to the company where the reordering rule should be created. Create a reordering rule for the product. Save the reordering rule. Note the AccessError related to mrp.bom. #### Root Cause: The MRP orderpoint computations read `product_id.bom_ids` directly. This is the product-template BoM relation and can include BoMs from other companies for a shared product. Reading fields on those BoMs, such as `product_uom_id`, can hit the standard `mrp.bom` multi-company record rule. #### Fix: Prefer `product_id.variant_bom_ids` before falling back to `product_id.bom_ids` in the affected orderpoint computations. This avoids reading template-level BoMs from other companies when the product has a variant-specific BoM for the current reordering-rule use case. opw-6253743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275493 Forward-Port-Of: odoo/odoo#267411

### Batch per all moves, not per product **Problem:** In https://github.com/odoo/odoo/pull/250526, moves are batched in order to prevent memory error in databases with many stock.move. However, the batching is done on the moves per product, meaning batches can be very small relative to the limit, and this causes unecessary queries compared to batching per all moves to process. **Solution:** Iterate through all moves rather than per product, and use/save the per product results directly in the relevant dicts. --- ### Batch and prefetch for initial product std_price **Problem:** When initializing products' standard price before replaying valuation, the first stock.move is read. This happens before any prefetching or batching occurs, so a query is made per move and contributes to performance issues. **Solution:** Batch and prefetch the products' first moves, then initialize the standard price. --- ### Use cached is_in and is_out values **Problem:** In `_get_valued_qty()`, `_is_in()` and `_is_out()` are called for each move, but these methods are already called for these moves and cached as `is_in` and `is_out`. **Solution:** Replace the method calls with the cached fields. If the move is not done, we fallback to the methods as the cached fields will be false for not done moves. --- **Perf Tables:** Record: product.template, each with AVCO automated valuation and a done in move Today: |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |1k |1.08s |264 |697ms |235 | |5k |2.74s |864 |2.23s |864 | |10k |4.83s |1375 |4.56s |1870 | At Date: |Record count|Time before|Queries before|Time after|Queries after| |------------|-----------|--------------|----------|-------------| |1k |3.10s |6109 |925ms |386 | |5k |14.68s |30299 |3.50s |1564 | |10k |26.98s |59173 |7.16s |3590 | opw-6134244 Forward-Port-Of: odoo/odoo#261624

Improvements(1)

[IMP] auth_signup: implement well-known change-password endpoint

Bug Fixes(34)

[FIX] account_reports: add a test for CTA table

Other(2)

[PERF] hr_holidays_attendance: `hr_leave_attendance_report`

Improvements(1)

[IMP] auth_signup: implement well-known change-password endpoint

Bug Fixes(34)

[FIX] account_reports: add a test for CTA table

Other(2)

[PERF] hr_holidays_attendance: `hr_leave_attendance_report`

[FIX] l10n_mx_edi: put CFDI fields in header_right_group

[FIX] sale_planning: fix visibility of sale_line_id in form view

[FIX] sign: fix a race condition that was causing errors on runbot

[FIX] l10n_mx_hr_payroll_account_edi: prevent error when removing payslip dates

[FIX] ai: remove inaccurate tool names from tool descriptions

[FIX] timesheet_grid: allow sample data injection with ActivityWatch

[FIX] l10n_vn_reports: negative sign for VAT in Sales Tax Report (VN)

[FIX] timesheet_grid: ignore notification counts in discuss rule regex

[FIX] timesheet_grid: assistant menu color fix

[FIX] account: CTA table fix in multi company

[FIX] l10n_sa_pos, l10n_sa_edi_pos: bigger ZATCA QR code on receipts

[FIX] auth_ldap: don't rely on demo data in test_auth_ldap

[FIX] l10n_it_edi{_*}: import vat taxes and their pension fund taxes in bill

[FIX] hr_holidays: Fix leave time selection traceback

[FIX] hr_attendance: fix systray time formatting

[FIX] account_peppol{_response}: remove response service if no journal

[FIX] l10n_cl: prevent AccessError for branch user

[FIX] point_of_sale: negate tax_base_amount on order reversal moves

[FIX] html_editor: avoid toolbar update crash after destroy

[FIX] purchase: bill matching same product lines

[FIX] l10n_br: fix address layout issue

[FIX] html_editor: fix non-deterministic test

[FIX] l10n_es*: include pos entries in VAT record books

[FIX] l10n_fr_account: fix sign of T formulas in tax report

[FIX] sale_mrp: deliver exact demand in kit COGS test

[FIX] account: resolve cash rounding account in invoice's company

[FIX] website_hr_recruitment: fix job location editing on website

[FIX] mrp: prefer variant BoMs on orderpoints

[FIX] stock_account: create Journal Entry for scrap

[FIX] project: Remove extra whitespace in visibility options

[FIX] stock_account: fix lot cost computation when move has no quantity

[FIX] mrp: validate moves added to validated MO

[FIX] mail: prevent push-to-talk banner moving call actions

[PERF] stock_account: Perf improvements for at date inventory valuation