Monday, May 4, 2026
22 changes · saas-19.3
New functionality added to Odoo
This update introduces a 'tare' function for Toledo scales within the Odoo system. This allows users to reset scale readings to zero, improving the accuracy of inventory tracking for products sold on these scales. This enhancement supports a key feature for businesses utilizing Toledo scales in their operations.
Original PR description
This PR adds the tare mode for Toledo scales. Related PR: https://github.com/odoo/odoo/pull/253328 Forward-Port-Of: odoo/odoo#262256 Forward-Port-Of: odoo/odoo#262027
Enhancements to existing features
This update enhances the accuracy of write-off reconciliation within the account reconciliation wizard. It now restricts displayed reconciliation models to those that are manually created or directly linked to the statement lines' journal, preventing potential errors and streamlining the reconciliation process. This ensures users only see relevant transactions.
Original PR description
In the account reconciliation wizard: - Only show manually created reconciliation models. - Only display reconciliation models that are not linked to any journal or are specifically linked to the journal of the statement lines. task-6059342 Forward-Port-Of: odoo/enterprise#111644
Resolved issues and error corrections
This update removes a confusing setting related to WHT return types in the Sri Lanka (l10n_lk) reports. Previously, the system was incorrectly mixing WHT closing entries with VAT closing entries, leading to potential reporting errors. This change ensures accurate reporting of withholding taxes.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814 Forward-Port-Of: odoo/enterprise#115576
This update prevents invoices from being silently rolled back to draft when a payment batch reconciliation fails due to approval rules. Previously, a third-party module could block the posting process, requiring users to manually correct the invoice. Now, the system correctly handles these scenarios, ensuring payments remain posted.
Original PR description
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module…
When unreconciling a batch payment from a bank statement line, delete_reconciled_line() resets the linked invoice to draft to recompute its amount_residual, then re-posts it. If a third-party module (e.g. Studio Approvals) silently rejects action_post for the current user, the invoice stays in draft and the user has to redo the work manually. This internal repost is not a business action, the move was already approved when initially posted, so it can run as sudo to bypass approval checks. Steps to reproduce: 1. Add a Studio Approval rule on account.move.action_post with an approver other than the current user 2. As a user without that approval right, post a vendor bill and register a payment 3. Add the payment to a batch payment 4. Reconcile a bank statement line with the batch payment 5. With the user without approval rights, try to unreconcile the bank statement line (delete_reconciled_line) - Expected: the bill stays Posted. - Actual (before fix): the bill silently rolls back to Draft because action_post is rejected by the approval hook. opw-6121448 Forward-Port-Of: odoo/enterprise#115579 Forward-Port-Of: odoo/enterprise#115241
This update ensures the session cookie is consistently set for Odoo.sh users, preventing frequent disconnections when sending messages. Previously, the cookie was only set if a specific database was defined, which caused issues with the Odoo.sh environment. This change enhances the overall reliability of the Odoo.sh connection.
Original PR description
Before this commit, the session cookie was only being set when the `db_name` is defined in `odoo.conf`. This was because it was used to identify the correct DB in a multi-DB setup. However, having the session cookie set also prevents frequent disconnects on every message when connected to an odoo.sh DB. After this commit, the session cookie is always set even when no `db_name` is defined. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261802
This update fixes a bug preventing users from seeing all available employee types within the Payroll module. The issue stemmed from a recent change that incorrectly filtered employee types based on country settings. This ensures all employee types are consistently visible, streamlining the employee onboarding process.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the Payroll module - Navigate to the Employees menu - Open an employee record - Go to the Payroll tab - Try selecting an Employee Type Issue: - Users are unable to see all employee types. This happens because some employee types do not have a country set, causing them to be excluded by the domain filter. However, users should be able to view all employee types regardless of the country field. Fix: - A recent change introduced in PR https://github.com/odoo/odoo/pull/258284 modified the domain, which caused this issue. This PR updates the domain to ensure all employee types are visible as expected. Task-6167327 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
This update fixes an issue preventing users from deleting time off allocations that were created after a payslip had been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off allocations can be deleted regardless of when they were created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#115659
Forward-Port-Of: odoo/enterprise#114895This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing errors when submitting to the DIAN tax authority. The change ensures that only the top-level node of the credit note has the correct namespace, aligning with DIAN requirements and preventing submission failures. This resolves a recurring problem identified previously.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#114725 Forward-Port-Of: odoo/enterprise#113643
This update resolves an issue where transcription summaries were incorrectly duplicated across multiple chat records. The fix ensures that summaries are now only posted to the relevant current chat, and also addresses a previous error that occurred when closing the composer window. This improves the user experience and prevents redundant notifications.
Original PR description
Before this commit, there was an issue where the message of the transcription summary would get posted to the chatters of all records of a given model. With this commit, the message is only posted on the current chatter. This commit also fixes a regression where closing the composer window would cause an exception to occur. task-6147951 Forward-Port-Of: odoo/enterprise#115829
This update fixes a technical issue that caused error messages when generating tax reports via the Odoo wizard. Now, if a certificate isn't set up, users receive a helpful message guiding them to configure one, preventing confusing tracebacks and ensuring smooth report submission.
Original PR description
Description of the issue this commit addresses: When sending the tax report or ec sales list xbrl file via the wizard to the authority, if no certificate has been set, a traceback shows up. This happens because some processes try to use the certificate without checking its existence. Desired behavior after the commit is merged: When sending via the xbrl wizard, if no certificate has been set up, an error offering the user to go to the certificate set up shows up and no traceback. task-6065382 Forward-Port-Of: odoo/enterprise#112951
This update ensures that vendor bills can now be searched using the 'expense_direct_cost' account type. Previously, this account type wasn't searchable, which limited reporting capabilities. The change removes a restriction on account code filtering during searches, improving search accuracy and usability.
Original PR description
The expense direct cost account (account_type: expense_direct_cost) should also be searchable on vendor bills, and search by account code should ignore filters (reverted change) task-id: [6138677](https://www.odoo.com/odoo/project/967/tasks/6138677) origin pr: https://github.com/odoo/odoo/pull/257850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260076
This update adds a configuration setting to enable logging of order data during support investigations. By including the order's receipt reference, it makes identifying and tracking specific orders in logs much easier. This enhancement improves our ability to quickly resolve customer issues.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262109 Forward-Port-Of: odoo/odoo#261792
This update addresses a user experience issue where a lingering Point of Sale session remained active after a user closed their browser tab or navigated away. This caused confusion for users and prevented proper session management. The fix ensures sessions are correctly terminated when the Point of Sale is no longer in use.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261207 Forward-Port-Of: odoo/odoo#258933
This update addresses a user experience issue where a session in the opening_control POS module wouldn't automatically close when the user left the browser tab or navigated away. This prevented confusion for users and ensured sessions were properly terminated, improving overall system stability. The change was driven by a reported problem (opw-6114420).
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 Forward-Port-Of: odoo/enterprise#115056
This update corrects a problem where existing ARCA connections persisted after duplicating an Odoo database. This prevented users from properly testing without impacting live production connections. The fix ensures ARCA connections are cleared when database credentials are updated, improving stability and preventing unintended production usage.
Original PR description
Problem and Cause: When duplicating a database with existing ARCA connections, the connections to ARCA webservices are not cleared. Users using the duplicate database may not realize that the ARCA connections are still present. This may lead to production connections getting used while users are testing. Solution: Clear connections to ARCA webservices when updating the credentials. Forward-Port-Of: odoo/enterprise#115068
This update resolves a crash that occurred when users attempted to fetch device information within the HR Attendance module. The issue stemmed from a missing server URL configuration, which prevented the system from properly connecting to the device. Now, users will receive a clear error message prompting them to set the necessary URL before attempting to fetch data.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the hr_attendance_zkteco module - Go to Settings → Device/Terminal - Click on “Fetch Terminal” Issue: - A traceback error occurs. Cause: - The server URL is not set in settings, so the server value is empty and causes an error. Fix: - Show a user error if the server URL is not configured, asking the user to set it before fetching the terminal. Task-6144254
This update adjusts the checksum verification process for the IoT scale certification module. It’s a necessary change to align with recent updates to the underlying IoT drivers, ensuring data integrity and continued functionality of the certified module. This update maintains the security and reliability of the IoT scale certification process.
Original PR description
This PR adapts the expected checksum for the scale certified module corresponding change in iot_drivers module Forward-Port-Of: odoo/enterprise#115825 Forward-Port-Of: odoo/enterprise#115771
This update resolves an issue where the full composer in the chatter didn't load the default email template body. Now, when using a default template, the full composer will correctly display the template's body content, ensuring emails are properly formatted. This improves the user experience and accuracy of email communications.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
This update resolves a bug where the state of a date field in forms was incorrectly being reset after saving. Typing a date into the field and saving would sometimes result in the field reverting to its previous value. The fix ensures the date field's state is correctly updated after the datepicker is closed, improving data consistency.
Original PR description
Step to reproduce: - Go on view form with a date field - Set the date with the input by typing the date with day and month (mm/dd or dd/mm), then press enter - Save the record - Redo the second step by with a different date - Save the record The assignation of the state.value done when closing the datepicker is useless and can put old a value in the state. The datepicker hasn't finished to update of the record that the assignation put back the old value of the record back in the state. The reason why it happens only after a save is still unknown. task-6095467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258111
This update fixes an issue where the tax return dashboard wouldn't display all tax return groups, showing only the first few. The change adjusts how many groups are automatically expanded, ensuring users can see all their tax return data. This improves the usability of the accounting dashboard for tax reporting.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update corrects a visual inconsistency in the project timesheet interface. Previously, the 'Time Remaining' value wasn't highlighted in red when negative, even though the label was. The fix ensures that negative time remaining values are displayed with the appropriate red warning indicator, improving clarity for users.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** In hr_timesheet, the remaining_hours field has a decoration-danger applied In sale_timesheet_enterprise, this field is overridden as portal_remaining_hours So, Added the corresponding decoration-danger on portal_remaining_hours. task-5404009 Forward-Port-Of: odoo/enterprise#114836 Forward-Port-Of: odoo/enterprise#113632
This update fixes a visual issue in the project timesheet reporting. Previously, the 'Time Remaining' value wasn't highlighted in red when it was negative. The fix ensures that negative time values are correctly displayed in red, providing clearer reporting for project managers.
Original PR description
**Steps to reproduce:** - Open project shared form view. - Go to the Timesheets tab. - Observe the Time Remaining value. **Issue:** - The Time Remaining label is red properly but its value does not becomes red even when the value is negative. **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red when value is negative **Task-id: 5404009** Forward-Port-Of: odoo/odoo#260996 Forward-Port-Of: odoo/odoo#240489