Tuesday, January 27, 2026
15 changes · saas-18.4
Enhancements to existing features
This update expands Odoo's language support to include Spanish, recognizing the significant Spanish-speaking population. This enhancement improves usability for a wider range of customers and aligns with Odoo's commitment to global accessibility. The change focuses on adding Spanish translations within the l10n_us module.
Original PR description
The official language is English, but Spanish is spoken by ~41 million. task-5247124 Forward-Port-Of: odoo/enterprise#105494 Forward-Port-Of: odoo/enterprise#105246
Resolved issues and error corrections
Fixes a rounding error in Argentine purchase withholding calculations when tax rounding is set per tax. This ensures payment withholding amounts round correctly, preventing small but important discrepancies in vendor payments and accounting records.
Original PR description
Steps to reproduce: - Set company to (AR) Responsable Inscripto - In Accounting > Settings, choose Round per Tax as the rounding method. - Go to Accounting > Taxes, duplicate IIBB WTH CABA 0%, and set Amount to 4.5%. - Open partner ADHOC SA, in the accounting tab add the new tax in Purchase Withholding - Create a new vendor Bill to vendor ADHOC SA with unit price 156,087.00 - Confirm and open Payment wizard Issue: Withholding amount is 7023.91, but it should be 7023.92 It occurs that the computed amount is 7023.915. Then when the tax repartition values are computed, the value is rounded and rounding difference are redistributed in the tax lines, so it seems the value has been rounded down. opw-5154585 Forward-Port-Of: odoo/odoo#241633
Website editors translating pages can now use undo normally after closing the color-code explanation dialog. This prevents editing interruptions and reduces the risk of manual rework when making translated website changes.
Original PR description
The builder uses `useHotkey` to bind the shortcuts for undo/redo. But when entering translate mode, if the dialog about color code appears, the hotkeys are associated with the active element of the dialog, and thus are skipped on dispatch when in the builder (and the dialog is closed). This commit shows the dialog in `onMounted` of the builder, instead of `onWillStart`, so that the dialog appears just after (instead of just before) the hotkeys are bound to the active element. Steps to reproduce: - On a DB with a website in several languages - Open the website builder in translate mode - Discard the dialog explaining the color code. This is the dialog needed to trigger the bug. If the dialog does not appear, try with a new private window - Do some edits in the page - Click in the sidebar (otherwise keys are handled in the iframe) - Press `ctrl+z` - Bug: it does not "undo" task-5481935
This fix prevents an IoT Box from marking an upgrade as complete when the underlying update command has failed. As a result, failed upgrades can be retried on the next start instead of leaving the device stuck on the wrong branch name.
Original PR description
If the upgrade fails, the branch name can already be set to the target one. Making the IoT Box not upgrading on next start. We now check `git` method return value, to ensure the command succeeded, before renaming the branch.
The Employees screen help section now displays correctly without overlapping content. This makes the employee action view clearer and easier to use, especially for administrators working in debug mode.
Original PR description
While performing a task I observed an improper view in employees action. Steps to Reproduce : 1. Activate debug mode and go to Employees/Employees/Employees menu 2. Go to its action 3. You will see improper view(content overlapping) in help section. These changes were added [here](https://github.com/odoo/odoo/pull/214810/changes#diff-99eff1b023601f0f844a2fa7efc6c4e62e13a8592d5b799113f848ac4c7565f8L549-R658 ). I have made the changes accordingly so that the Help content looks fine in both Employees menu and action. before : <img width="1695" height="752" alt="image" src="https://github.com/user-attachments/assets/6a847373-5ac2-4877-a07f-ad58338429c5" /> after : <img width="1272" height="823" alt="image" src="https://github.com/user-attachments/assets/16b50843-e736-490a-8a00-44848c6011fa" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue causing a 'NameError' in the TFN dashboard warning, preventing incorrect warnings from appearing for employees applying for TFN. The fix ensures the warning calculation accurately identifies employees meeting the criteria, improving payroll reporting accuracy. This upgrade is part of the standard Odoo 18.4 release.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998
Forward-Port-Of: odoo/enterprise#103777This update resolves a technical issue that could cause errors when processing Peruvian electronic invoices (PE DI) within Odoo Enterprise. The fix ensures that the system handles cases where invoice data is missing, preventing unexpected tracebacks and improving the reliability of the invoicing process. This ensures smoother and more accurate invoice generation and submission for our Peruvian clients.
This update addresses a limitation in how users manage their consent for online synchronization. Previously, a short-lived access token caused issues with the consent link in the chat interface. Now, a more stable consent token is used, linked to the user, ensuring a reliable process for granting access.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105392 Forward-Port-Of: odoo/enterprise#105202
This update fixes an issue preventing appointment bookings from showing correctly at the end of the day. The system was incorrectly interpreting the end of the day as an unavailable slot, blocking bookings that started at 23:00. The fix ensures that the end-of-day slot is properly recognized, allowing for bookings to be scheduled until 23:59:59.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#104927 Forward-Port-Of: odoo/enterprise#100853
This update automatically matches bank statements with invoices when the reference information is identical. Previously, the system prevented this match, requiring manual intervention. This change ensures faster and more accurate reconciliation of bank statements, streamlining financial processes.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. ### Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. ### After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA)
This update resolves an issue where users with limited sign rights couldn't access the sample document template. The fix ensures that users can create and manage sign items for the copied template, allowing them to successfully use the sample. This improves the user experience for all users.
Original PR description
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our…
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it. 2. Add some sign items to the template, and send it for a signature request. 3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'. Access Error: Blame the following rules: - sign.item: group_sign_user: Create and manage template items **Cause** When the template has an associated sign request, it is copied. The problem is that the user currently doesn't have enough rights to create sign items for the copied template: https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101 **Change** Change the `user_id` of the new template to allow creating the sign items for it. opw-5254566 Forward-Port-Of: odoo/enterprise#102227
This update resolves a technical problem in the demo data for the Mexican payroll modules. Previously, the demo company name was being overwritten, causing issues with invoice and payment processing (CFDI stamping) within the demo environment. This change ensures the demo data accurately reflects the company and partner information.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases. Forward-Port-Of: odoo/enterprise#103870 Forward-Port-Of: odoo/enterprise#102558
This update resolves a bug that caused the follow-up report to crash when users unfolded partner lines while prefix groups were enabled. The fix corrects an error in how the report processed data, ensuring stability and reliable report generation for all users.
Original PR description
When prefix groups were enabled, and a prefix group line had been unfolded, the report crashed when trying to unfold the partner. This happened because res_ids_map is computed for each of the unfolded lines, including the prefix groups one, which then had no 'res.partner' key, causing a key error. Forward-Port-Of: odoo/enterprise#105525
This update resolves a problem in the payroll testing process where contract end dates weren't being calculated correctly. The fix ensures contracts automatically end after two years, aligning with standard payroll practices. This improves the reliability of payroll calculations and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894
This update resolves an issue in Odoo's Web Studio where it could incorrectly link fields to non-searchable data types. This caused warnings and errors, particularly in business settings. The change ensures that Web Studio only creates relational fields with searchable data, improving stability and reliability.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158 Forward-Port-Of: odoo/enterprise#105607