Tuesday, July 28, 2026
8 changes · saas-18.4
Enhancements to existing features
Odoo now supports the standard web address that browsers and password managers use to find where users can change or reset their password. This helps tools like Chrome, Safari, 1Password, and Bitwarden send users directly to the right Odoo password page, improving convenience and consistency.
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
Resolved issues and error corrections
This change stabilizes an automated test for cancelling a link popover while an attachment upload is in progress. It prevents rare false failures on busy test infrastructure, helping keep development and release checks dependable without changing user-facing behavior.
Original PR description
The test that verifies the behavior of cancelling the link popover during an attachment upload relies on a hard-coded delay. Occasionally, when the test runs on an overloaded runbot infrastructure, the upload manages to complete before the discard happens. This commit fixes this by making sure the upload never completes within the test. runbot-940190 runbot-944098
The LDAP authentication test now creates its own template user instead of relying on sample demo data. This makes testing more reliable for databases installed without demo data and helps prevent false failures during validation.
Original PR description
Steps to reproduce the bug: - Load a database without demo data - Install `auth_ldap` - Run the `TestAuthLDAP.test_auth_ldap` test Problem: The test failed with a 404 error on `POST /web/login`: `requests.exceptions.HTTPError: 404 Client Error: NOT FOUND for url: http://127.0.0.1:8069/web/login`. The mocked `_get_ldap_dicts` hardcoded the LDAP config's template `user` as `(6, "Marc Demo")`, assuming the demo user `base.user_demo` exists with that id. Without demo data, `res.users(6,)` does not exist, so `_get_or_create_user`'s `SudoUser.browse(conf['user'][0]).copy(...)` raised a `MissingError`, which Odoo's HTTP dispatcher turns into a 404. Solution: Create a dedicated "user template" at the start of the test and use it as the LDAP template user, instead of hardcoding a demo-data record id. This makes the test self-contained and independent of whether demo data is loaded. runbot-243648 Forward-Port-Of: odoo/odoo#277463
The website job listings country filter now remains clickable even when a search term has no results in the currently selected country. Search keywords are also preserved when switching country filters, helping candidates refine job searches without losing context.
Original PR description
[FIX] website_hr_recruitment: fix country filter Bug reproduction: 1 - Recruitment, you need to have 1 remote and 1 US jobs at least. 2 - Go to job page in website, activate country filter. 3 -…
[FIX] website_hr_recruitment: fix country filter
Bug reproduction:
1 - Recruitment, you need to have 1 remote and 1 US jobs at least.
2 - Go to job page in website, activate country filter.
3 - Select US jobs and search for the remote job.
4 - All countries filter is readonly and it is not pressable.
Bug cause:
1 - Check is done with jobs value
1.1 - If no matching, readonly button is displayed.
Bug solution:
1 - count_per_filter is used instead of jobs
1.1 - Even there are matchings for other countries, it shows.
2 - Also, searched keyword is added to filter url
2.1 - When there is search in other country and we click to it:
2.2 - The searched keyword will be still there.
task-6284436
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#277726The website editor now shows the correct title color when users customize heading colors in a theme color preset. This makes the preview more reliable, helping users confirm branding changes before applying them.
Original PR description
Steps to reproduce: - Go to Edit mode - Go to the Theme tab - Open a color preset to customize it - Change the "Headings" color => The color of "Title" did not change in the preview By changing the tag from "h3" to "h1", the color in the preview is now correctly updated in the theme tab. "fs-4" is added to keep the previous size. task-6299680
This fix ensures an HR Attendance overtime test uses a consistent timezone setup, so automated checks pass whether demo data is installed or not. It reduces false test failures and helps keep attendance overtime calculations reliable during development and releases.
Original PR description
The `test_overtime_hours_multiple_flexible_resources` test fails if run with demo data. # Cause The default value for the timezone of a `resource_calendar` is computed as follows :…
The `test_overtime_hours_multiple_flexible_resources` test fails if run with demo data. # Cause The default value for the timezone of a `resource_calendar` is computed as follows : https://github.com/odoo/odoo/blob/8974a6283a8e1f5bc00601da26883ea0fadf180d/addons/resource/models/resource_calendar.py#L105 This make it so the resulting value is different if demo data is loaded or not : With => UTC Without => Europe/Brussels In `test_hr_attendance_overtime`, we create a flexible calendar without giving it a timezone, but we create a flexible employee while forcing its timezone to UTC : https://github.com/odoo/odoo/blob/8974a6283a8e1f5bc00601da26883ea0fadf180d/addons/hr_attendance/tests/test_hr_attendance_overtime.py#L97-L111 So the employee's calendar's timezone is subject to change while the employee's timezone is not. This may result in cases were they are not equal This provoke issues in our test because : When updating the overtime, we first fetch every attendance of the employee to determine the `start` and `stop` dates used to emulate the working hours of an employee (in the case of a flexible calendar). To get the start day of every attendance, we use the calendar's timezone : https://github.com/odoo/odoo/blob/8974a6283a8e1f5bc00601da26883ea0fadf180d/addons/hr_attendance/models/hr_attendance.py#L290 In our test, the first attendance is the 2nd January 2023, which is a monday. With the timezone shenanigans, it actually ends up on the 1st January 2023, which is the week before. This [PR] made it so the emulated working hours start the first day of the week, instead of `start`, so we end up computing the working hours for the wrong week, which in turn make the overtime calculation wrong. [PR]: https://github.com/odoo/odoo/pull/269820/changes runbot-944212
This fixes a display issue where Mexican CFDI invoice fields could disappear when Colombian e-invoicing was also installed. The fields are now placed in a stable invoice header area, so Mexican users can reliably see the CFDI Origen information.
Original PR description
The CFDI fields used //sheet/group//group[last()], which targets the last group by position. Once l10n_co_edi adds its group after header_right_group, the fields land in it instead, and it is invisible unless country_code is CO, so CFDI Origen disappears on MX invoices. Use //group[@id='header_right_group'], like l10n_co_edi already does, so placement no longer depends on what modules are installed. Task Adhoc side: 67269 Forward-Port-Of: odoo/enterprise#124545
This fixes FedEx label generation so outbound shipments are no longer incorrectly treated as return shipments when return labels are enabled. Businesses using FedEx returns should now see the expected reference information on original shipment labels, improving traceability and reducing label confusion.
Original PR description
## Backport of #118659 Issue ----- When setting the delivery method to create return labels aswell, the reference (`REF`) field is not present on the original outbound shipment. Steps to reproduce ----- - Setup Fedex - Enable returns - Create a product (set weight) - Create a delivery for the product - Set carrier as Fedex - Validate delivery - Open the label > REF field is empty Cause ----- Fedex doesn't include references on the label of returns. When the option for returns is enabled, the outbound shipment is marked as a "Courtesy return". It doesn't make sense to specify a return reason on the original shipment. ----- Ticket: opw-6101620 Forward-Port-Of: odoo/enterprise#125629