Daily updates from Odoo
Monday, July 27, 2026
7 changes · 17.0
Enhancements to existing features
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 Chan
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
Resolved issues and error corrections
This fix prevents Swiss payroll ELM transmission from failing when a related salary rule has been archived. It helps payroll users continue processing monthly employee values without unexpected interruptions caused by archived configuration records.
The Swedish SIE4 general ledger export now uses the actual configured fiscal year dates instead of assuming every fiscal year lasts exactly one year. This prevents mismatches between the declared reporting period and the accounting data included in exports, especially for shortened or extended fiscal years.
Original PR description
## Issue: Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year. ## Steps to reproduce: - Create a fiscal year A of one month for…
## Issue: Exporting the general ledger as SIE4 set the duration of fiscal years to one year from the starting date of the fiscal year. ## Steps to reproduce: - Create a fiscal year A of one month for year X-1 (December 1st to December31th year X-1) - Create a fiscal year B of 1 year and 1 month (January 1st Year X to January 31th year X+1) - Create Invoices in November year X-1, December year X-1, year X and in January year X+1 and confirm them - Go to General Leder - Set date to the fiscal year B - Export as SIE4 ### Current behavior: - **for previous fiscal year** - declared fiscal year (#RAR field) goes : - from fiscal year X date_from -1 year - to fiscal year X date_to -1 year - However data are computed: - from fiscal year X date_from -1 year - to fiscal year X date_from -1 day - **for current fiscal year** - declared fiscal year (#RAR field) goes : - from fiscal year X date_from - to fiscal year X date_to - However data are computed: - from fiscal year X date_from - to fiscal year X date_from +1 year ### Expected behavior: Declared fiscal year match the one that is use for computation. - for previous fiscal year - from fiscal year X-1 date_from - to fiscal year X date_from -1 day - for current year - from fiscal year X date_from - to fiscal year X date_to Cause: Current year length was wrong because it [relied on](https://github.com/odoo/enterprise/blob/22b4100006ec24bf6e4b64042cbfdba360fcf470/l10n_se_sie4_export/models/account_general_ledger.py#L139-L140) the next_date_from which was wrong. opw-6264766
This commit fixes an issue with the campaign_id field on mailing.mailing so that we can only use actual utm.campaign for it. Before this commit, when enabled it was possible to select any type of campaign even one created by marketing automation. As those creates a utm campaign linked to them. Difference being they are marked as auto campaigns. So when selecting those, they aren't shown in the campaigns' menu's views. To fix this we add a domain to the campaign_id field so that the user ca
Original PR description
This commit fixes an issue with the campaign_id field on mailing.mailing so that we can only use actual utm.campaign for it. Before this commit, when enabled it was possible to select any type of campaign even one created by marketing automation. As those creates a utm campaign linked to them. Difference being they are marked as auto campaigns. So when selecting those, they aren't shown in the campaigns' menu's views. To fix this we add a domain to the campaign_id field so that the user can only select actual campaigns. Disabling the previously mentioned behavior. task-6290440
When an employee has many validated accrual allocations on the same leave type and at least one approved future leave on that leave type, opening the time off dashboard, the employee form, "My Profile" or validating a new allocation becomes very slow. The slowdown gets worse with each extra allocation. ### Steps to reproduce 1. Install Time Off. 2. Time Off > Configuration > Accrual Plans: create a plan. 3. Time Off > Management > Allocations: create and validate an Accrual Allocation fo
Original PR description
When an employee has many validated accrual allocations on the same leave type and at least one approved future leave on that leave type, opening the time off dashboard, the employee form, "My…
When an employee has many validated accrual allocations on the same leave type and at least one approved future leave on that leave type, opening the time off dashboard, the employee form, "My Profile" or validating a new allocation becomes very slow. The slowdown gets worse with each extra allocation.
### Steps to reproduce
1. Install Time Off.
2. Time Off > Configuration > Accrual Plans: create a plan.
3. Time Off > Management > Allocations: create and validate an Accrual Allocation for an employee (e.g., Paid Time Off).
4. Time Off > Management > Time Off: create and approve a request for the same employee starting a few months in the future.
5. Create and validate several more accrual allocations of the same type for the same employee. Each validation gets progressively slower.
6. Open the dashboard or employee form; Odoo hangs for several seconds.
### Cause
The reason is that `hr.employee._get_consumed_leaves` and `hr.leave.allocation._process_accrual_plans` call each other in a loop:
```text
_get_consumed_leaves
_get_future_leaves_on
_process_accrual_plans
_get_leaves_taken
_get_consumed_leaves
...
```
The existing `precomputed_allocations` guard only stops re-entry for the single allocation being simulated. All sibling allocations on the same employee and leave type still trigger a full nested simulation, so the work grows very fast with the number of allocations.
On top of that, `_process_accrual_plans` walks the timeline one tick at a time (one day for daily plans). On every tick it calls `_get_leaves_taken`, which calls `_get_consumed_leaves` again. For most of those ticks nothing has changed: no leave has entered the window, the allocation has not hit its capacity, and the `leaves_taken` value is the same as the previous tick. But the heavy work runs anyway.
### Fix
1. Memoize `_get_future_leaves_on` by `(allocation.id, accrual_date)` on a per-request dict carried through `env.context`.
2. In `_process_accrual_plans`, fetch the relevant leave `date_from` values once before the `while` loop and only recompute `leaves_taken` when it can actually have changed: a new leave date entered the window, or the allocation was at full capacity in the previous iteration. When the employee has no relevant leaves on this leave type, `leaves_taken` stays `0` for the whole loop and the heavy call is skipped entirely.
opw-5975939Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0: Internal compiler error #12345: error mmapping datablock to 30283637 Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubl
Original PR description
Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0: Internal compiler error #12345: error mmapping datablock to 30283637 Root cause: the…
Windows nightly builds have been failing for several days with this obscure NSIS error message in Odoo 19.0:
Internal compiler error #12345: error mmapping datablock to 30283637
Root cause: the accumulated size of `.po` files across all modules has grown past a threshold where the NSIS solid compressor tries to mmap a buffer larger than the ~2 GiB address space available to the 32-bit makensis running under Wine. Simply dropping the `/SOLID` option makes the build pass but nearly doubles the size of the final installer, which is not acceptable.
The chosen fix is to pre-bundle all `.po` files into a single solid 7z archive and extract it at install time using the `Nsis7z` plugin. This keeps the NSIS datablock well below the and yields comparable or better final installer size than the previous approach, along with faster build times.
While at it, this commit also modernizes the Windows build environment to unblock a separate wine-devel install regression that has been affecting Odoo 17.0 nightlies on Debian Bookworm.
Changes:
- Bundle `.po` files into `i18n_bundle.7z` inside the build container prior to invoking makensis; extract it at install time via the `Nsis7z` plugin.
- Bump the base image from Debian Bookworm to Trixie.
- Switch from `wine-devel` to `wine-stable`, which resolves the install regression on Bookworm-based builds.
- Upgrade NSIS to the latest release.
- Refactor the NSIS installation step to remove the hardcoded version from `package.py`.
This fix is made in Odoo 17.0 to unblock the wine-devel issue there and to benefit from the smaller installer size on supported stable branches.Code cleanup and technical improvements
Owl considers declared component props mandatory unless they are marked optional. The `required: true` flags therefore duplicate the default and add noise to the prop definitions. Remove those flags from `PlacesAutoComplete`, all four props remain mandatory.
Original PR description
Owl considers declared component props mandatory unless they are marked optional. The `required: true` flags therefore duplicate the default and add noise to the prop definitions. Remove those flags from `PlacesAutoComplete`, all four props remain mandatory.