Daily updates from Odoo
Monday, April 27, 2026
24 changes · master
Resolved issues and error corrections
This update fixes an issue where employees were incorrectly paid 80% for rest days when on sick leave. The change ensures that employees are paid their full wage on rest days, aligning with the definition of a sickness day. This corrects a payment discrepancy and ensures accurate payroll calculations.
Original PR description
Currently, if a sick leave is spread over a weekend, the work entry type set on the saturday and sunday will be the sick leave type. If an employee is entitled sickness allowance (which is paid 80%), it means that we will be paying them 80% for their rest days as well. However, as per the definition, a sickness day is a day on which an employee is absent from work by reason of being unfit due to injury or sickness. If an employee is not expected to be at work (rest day), that day cannot be considered a sickness day. If this rest day is paid (which is done by default in our module), we should thus pay the full wage on that day and not a reduced 80%. task-6079736 Forward-Port-Of: odoo/enterprise#115049 Forward-Port-Of: odoo/enterprise#113486
This update resolves a UI issue that occurred when sign templates included roles with assigned users. A technical change related to binary data handling caused errors during page loading, leading to a broken display. The fix converts binary data to a standard format for reliable rendering, ensuring a smooth user experience.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Create sign template with one role. - Set 'assign to' value to that role. - Try to refresh the page or again open the template. Issue: - sign item and roles are not render on template properly and UI get broken. - ConnectionLostError occurs when loading sign template with 'assign to' value on role. Cause: - After recent changes, Binary fields (avatar_128/avatar_1920) now return BinaryValue objects instead of base64 strings. - These objects are not JSON serializable and cause UnicodeDecodeError during RPC response serialization. Solution: - Convert BinaryValue to base64 string using .to_base64() before returning in get_template_items_roles_info. task-6122941 Forward-Port-Of: odoo/enterprise#113911
This update resolves an error that occurred when users attempted to group depreciation schedules by analytic plans. The issue stemmed from an incorrect formatting of data within the database query, specifically surrounding analytic account IDs. Removing unnecessary parentheses corrected the query and allows users to successfully group by analytic plans.
Original PR description
Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule. Steps to replicate: - Install `accountant` with demo, turn on `Analytic Accounting` from settings. -…
Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule.
Steps to replicate:
- Install `accountant` with demo, turn on `Analytic Accounting` from settings.
- Open `Accounting > Review > Depreciation Schedule`.
- Click `Analytic` > Add a `Plan`.
Error:
```
psycopg2.errors.UndefinedFunction: operator does not exist: text = record
LINE 12: WHERE key IN (('7', '16', '8', '15', '6', '9', '...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
Cause:
- At line [1], we pass a tuple of `analytic_account_ids`, which is then wrapped again in parentheses at line [2].
- This results in the IDs being enclosed in double parentheses, e.g. `(('7', '16', '8', '15', '6'))`.
- When the `IN` clause is used with this double-parenthesized tuple, PostgreSQL treats it as a list containing a single record. It then tries to compare `key` (a text value) with that record `('7', '16', '8', '15', '6')`, effectively resulting in a `text = record` comparison, which is invalid and causes error.
Solution:
- Removed the extra parentheses from the query.
[1]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L124
[2]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L121
sentry-7423121981
Forward-Port-Of: odoo/enterprise#114334This update resolves a critical error that could cause payroll processing to fail when employee bank account information is incomplete. The change safely handles situations where bank accounts aren't defined, preventing crashes and ensuring accurate CFDI generation. This improves the stability and reliability of the payroll module.
Original PR description
Accessing the employee bank accounts using index [0] raised an IndexError when no accounts were defined. Additionally, computing the CLABE flag using len() caused a TypeError when the account number was missing. This change uses a safe recordset slice to avoid accessing empty records and guards the length check to only evaluate when a value is present. It prevents crashes while keeping the original behavior unchanged and avoids sending invalid empty values in the CFDI. Forward-Port-Of: odoo/enterprise#114073 Forward-Port-Of: odoo/enterprise#113987
A test within the Odoo Enterprise payroll module (l10n_in_payroll) was failing due to a missing employee type ID. This update correctly assigned a required employee type ID, resolving the test failure and ensuring accurate payroll calculations for Indian employees. This fix improves the stability and reliability of the payroll processing.
Original PR description
[FIX] l10n_in_payroll: fix missing employee type id
Bug reproduction: Go to master and try to run test_in_hr_version_percentage_computation test by installing l10n_in_hr_payroll only. It fails and throws an error.
Bug cause: The employee has not employee_type_id and when with Form is used, employee_type_id is a required field and must be filled in.
Bug solution: I assigned the Indian employee type as a employee_type_id
Runbot Error:
Link 1: https://runbot.odoo.com/odoo/error/241955
Link 2: https://runbot.odoo.com/odoo/error/242490
task - 6117742
Forward-Port-Of: odoo/enterprise#113692This update corrects a problem where the employee's salary wasn't correctly displayed when creating an offer from the employee form. The fix involved updating the context passed to the action, ensuring the correct salary information is now populated. This improves the accuracy of offer creation workflows.
Original PR description
task-5979287 Forward-Port-Of: odoo/enterprise#114957 Forward-Port-Of: odoo/enterprise#109067
This update significantly reduces the time it takes to load timesheets, particularly in systems with many projects. The change optimizes a search process to avoid unnecessary database calls, resulting in a faster and more responsive user experience. This improves efficiency for users managing their timesheets.
Original PR description
The loading time of timesheets was extremely high (around 4 seconds) for databases with many projects and tasks. This commit aims to resolve the time required to load by setting `count_limit` on the search for project suggestions to avoid calling `search_count` as it is uneccesary. task-6128133 Forward-Port-Of: odoo/enterprise#114697
This update corrects a critical issue where the DIAN web service was incorrectly overwriting customer contact information (names and emails) with fiscal data, leading to lost sales data. The fix now intelligently handles email differences, creating a backup contact and preserving the correct commercial information, ensuring accurate invoice delivery and preventing manual data corrections.
Original PR description
The DIAN web service was overwriting partner names and emails with fiscal data, causing data loss for CRM contacts. The fiscal email often differs from the commercial one, and the overwrite broke the sales flow by sending invoices to the wrong address. Users had no standard workaround short of manually re-entering emails after every invoice generation. Instead of blindly overwriting, only update empty fields and create a child invoicing contact when the DIAN email differs from the existing one. Also remove the automatic onchange and periodic re-fetch triggers to leave existing data under user control. task-5912005 Forward-Port-Of: odoo/enterprise#115018 Forward-Port-Of: odoo/enterprise#114017
This update corrects an issue where invoices submitted to DIAN were incorrectly marked as 'failed' due to expected status update failures. The fix ensures invoices are properly marked as 'accepted' after successful DIAN transmission, preventing problems like QR code generation. This improves the accuracy of invoice status reporting.
Original PR description
Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document. The problem with that approach is that we will regularly send status…
Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document. The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484 Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`). As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`. This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state. The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios. The most common setup where the error happens is for invoices that have 2 DIAN documents: 1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`) 2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events) opw-6108318 opw-5931442 opw-6034035 Forward-Port-Of: odoo/enterprise#113929
This update fixes an issue where resource leaves weren't properly reflected in Google Calendar availability, leading to incorrect booking options. The team also removed unnecessary code related to minimum schedule hours, as Google Reserve slots are pre-defined. This ensures accurate availability and a smoother booking experience.
Original PR description
Resources on leave were still showing as available in BatchAvailabilityLookup responses because unavailabilities were not checked. Also remove the min_schedule_hours offset copied from the frontend logic. It is not relevant for Google Reserve as slots are pre-built in the feeds. Task-6150788 Forward-Port-Of: odoo/enterprise#114793
This update fixes an issue where signature overlays were causing data loss in PDF documents. Now, the original PDF structure, including metadata and bookmarks, is fully preserved when signatures are added. This ensures consistent and accurate PDF documents.
Original PR description
Instead of rebuilding the PDF by copying content, metadata, and bookmarks, we now duplicate the original document first and then apply the signature overlays. This ensures the full structure and settings are preserved without loss. task-6083291 Forward-Port-Of: odoo/enterprise#115048 Forward-Port-Of: odoo/enterprise#114618
This update resolves an issue where CFDI generation for payroll payslips failed due to discrepancies in decimal precision. The fix ensures all payroll amounts are rounded to 2 decimal places before CFDI generation, aligning with Mexican tax regulations. This prevents errors and ensures accurate CFDI stamping.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update prevents unnecessary warnings from appearing when a task template is moved to a project that doesn't support timesheets. This change ensures a smoother workflow for users managing task templates and avoids distracting notifications. It addresses a previous issue identified in a related community pull request.
Original PR description
A task template should not trigger any warning about timesheets that remain in the previous project when changing its project to a non-timesheetable project. related Community PR: https://github.com/odoo/odoo/pull/230118 task-5140018
This update corrects a technical issue where a duplicate record was incorrectly introduced in the French reporting module (l10n_fr_reports). The fix removes this redundant record, ensuring accurate reporting data and preventing potential data inconsistencies. This resolves a minor technical problem.
Original PR description
this forward port wrongly introduced an already existing record https://github.com/odoo/enterprise/pull/114739 Forward-Port-Of: odoo/enterprise#114907
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic lines during editing, preventing orphaned lines and maintaining data integrity.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update resolves a technical error in the processing of French tax returns (liasse fiscale). A missing call to the parent function caused a test failure, which has now been corrected. This ensures accurate reporting and compliance for French businesses using Odoo Enterprise.
Original PR description
When merging the sending of the liasse fiscale, super() wasn't called anymore in action_submit and led to an assertError in test_state_progression() test
```
FAIL: Subtest TestAccountReturn.test_state_progression (return_type=account.return.type(186,))
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/tests/test_account_returns.py", line 2087, in test_state_progression
self.assertEqual(account_return.state, 'paid')
AssertionError: False != 'paid'
```
runbot-275061
Forward-Port-Of: odoo/enterprise#114585A recent change to the l10n_mx_edi module broke a key test related to rounding calculations for Mexican tax invoices. This update reverted the rounding mode to 'mixed', resolving the test failure. This ensures accurate tax calculations are being verified within the module.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
This update corrects a warning message that incorrectly flagged transactions using the Cash Basis accounting method as having an inactive Construction Industry Scheme. The fix ensures that CABA entries are properly excluded from this check, preventing unnecessary alerts and improving the accuracy of reporting. This change impacts users utilizing Cash Basis accounting and CIS reporting.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
A minor bug preventing the generation of EC sales returns has been fixed. This issue arose after a recent update to the ec sales list report, and was caused by a simple typo. This ensures that sales returns are accurately tracked and reported.
Original PR description
With the rework of the ec sales list report(https://github.com/odoo/enterprise/commit/4096c1fcbd7f31f70153058d2e3f9eab6d82e356#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29), the return generation of this type became generic but a small bug appeared. It was not generating anymore because of a typo. Forward-Port-Of: odoo/enterprise#114815
This pull request addresses several usability issues within the timesheet module, including a fix for automatically showing the timesheet systray, improved inline form appearance, and pre-filling timesheets with relevant project and task data. It also corrects a visual bug related to the timer display, ensuring it remains aligned after systray closures.
Original PR description
*: timesheet_grid,timesheet_grid_hr_attendance,helpdesk_timesheet # [FIX] timesheet_grid_hr_attendance: open timesheet systray on check-in Before this commit, the user had to re-open the systray in…
*: timesheet_grid,timesheet_grid_hr_attendance,helpdesk_timesheet # [FIX] timesheet_grid_hr_attendance: open timesheet systray on check-in Before this commit, the user had to re-open the systray in order to open the timesheet systray. Now, it is directly showed to the user upon check-in, without having the systray being closed automatically. # [FIX] web_enterprise: required project is not underlined bolder when hovered In this commit, we ensure that the border under the project in the timesheet inline form is bolder when hovered. # [FIX] timesheet_grid,helpdesk_timesheet: prefill timesheets in systray In this commit, we enable timesheets in the systray to be prefilled with project, tasks, and helpdesk tickets if the user opens the systray from any of these views, provided that the fields were empty. Further, say a project is already set, then any opened task from that project will also be populated upon opening the systray under the condition that both projects match. The same reasoning applies to helpdek tickets. # [FIX] sale_timesheet_enterprise: conditionnal class on timesheet timer After closing the systray, the 'billable' radio button ended up on a new line because the class on the timer was not correctly removed. With this commit, the button will remain on the same line as the timer, even after closing and re-opening the systray. # [FIX] sale_timesheet_enterprise: hide assistant button This commit adds conditions to display the button opening the timesheet assistant. Prior to this, the button was displayed even if the setting is not active on the user. See odoo/odoo#257930 task-6088779 Forward-Port-Of: odoo/enterprise#114803 Forward-Port-Of: odoo/enterprise#113189
This update fixes an issue where profit and loss accounts were incorrectly appearing on balance sheet reports. The change prevents grouped reporting from miscategorizing accounts, ensuring balance sheets accurately reflect assets, liabilities, and equity. This improves the reliability of financial reporting.
Original PR description
…er unfolded Since the groupby at report level, lines such as "Current Year Unallocated Earnings" were displaying profit and loss accounts in the balance sheet, which is not a desired behavior. task-6152675 Forward-Port-Of: odoo/enterprise#114885
This pull request corrects a typographical error in a test file within the marketing automation module. These tests ensure the functionality of automated marketing campaigns. The fix improves the reliability of the testing process and prevents potential issues with campaign execution.
Original PR description
Forward-Port-Of: odoo/enterprise#115315
This update fixes a problem where Wise recipient matching failed due to differences in data like spacing or casing. Now, the system uses only financial details (account numbers, routing numbers, IBANs) for matching, ensuring accurate recipient identification. This improves the reliability of direct deposit payments.
Original PR description
Previously, _generate_wise_key included partner name and email in the matching key. If these differed between Odoo and Wise (e.g. trailing spaces, casing), the match would fail and a duplicate recipient was created. Use only financial identifiers (account type, routing number, account number) which are the actual unique identifiers for bank accounts. This is for example important with IBAN accounts as the won't have an email stored in Wise. From this we combine IBAN and SWIFT recipients into one non-US group. Forward-Port-Of: odoo/enterprise#115209 Forward-Port-Of: odoo/enterprise#113234
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from printed reports like the Trial Balance. This commit ensures that total lines, even those without a parent, are always included when printing, providing a more complete and accurate report view. This improves the usability of our financial reporting tools.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#115011 Forward-Port-Of: odoo/enterprise#114084