Tuesday, April 28, 2026
14 changes · master
Resolved issues and error corrections
This update fixes a problem where Wise recipient matching failed due to slight differences in data (like spacing or capitalization) between Odoo and Wise. Now, the system uses only financial details like account numbers and routing numbers for matching, ensuring accurate recipient identification and preventing duplicate entries, especially for IBAN accounts.
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 resolves an issue where Odoo couldn't import CODA files from Belgian banks when the detail sequence (3.2) was incremented. Banks sometimes provide files with updated sequences, and this fix allows the import process to handle these changes without triggering an error. This ensures seamless bank statement imports for our BE customers.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update resolves a persistent scrollbar flicker issue in the Gantt chart. The problem stemmed from an incorrect row height calculation, which has now been corrected. The fix ensures a smoother and more reliable Gantt chart experience for users.
Original PR description
This commit fixes an issue where the scrollbar would flicker uncontrollably at certain scroll positions. This occurred because grid elements were constantly appearing and disappearing at the edge of the viewport on every animation frame. The root cause was a discrepancy in row height computations introduced in https://github.com/odoo/enterprise/pull/101732. The virtual grid was receiving row heights 8px smaller than the actually rendered rows, leading to miscalculations in visibility. To fix this, the problematic 8px change is reverted. The original design requirement (fitting the progress bar) is instead fulfilled by explicitly adding height to group rows, and providing additional space to regular rows on smaller screens. Forward-Port-Of: odoo/enterprise#115283
This change updates the email address used to receive responses to automated emails from clients. Previously, emails were sent to iap@odoo.com, which led to some responses. Now, emails are sent to noreply@odoo.com for better management and tracking.
Original PR description
The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097
This update resolves an issue where account return tours weren't functioning correctly across different localization settings (l10n). The fix addressed a missing tag that caused errors, preventing the tours from running properly and leading to unhandled issues. This ensures all users, regardless of their location, receive the correct return tour guidance.
Original PR description
Before, the account return tour was not running with every l10n installed du to a missing tags. This leads to errors that were not catched like missing super call on a submit action. Forward-Port-Of: odoo/enterprise#115290
This update resolves an issue where financial reports (FAIA export) were incorrectly linking invoices to accounts. The fix ensures that the AccountID in sales and purchase invoices matches the AccountID defined in the company's general ledger, improving the accuracy of financial reporting. This was part of a larger effort to standardize export formats.
Original PR description
This is one of several commits fixing the FAIA xml export. The Invoice/Line/AccountID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match an account defined in MasterFiles/GeneralLedgerAccounts/Account/AccountID. As the latter uses account_code since PR #65221, the former should too. opw-5427296 [Link](https://www.odoo.com/odoo/unassigned-tasks/5427296) Forward-Port-Of: odoo/enterprise#114254 Forward-Port-Of: odoo/enterprise#113455
This update corrects a technical issue preventing the proper handling of binary data within the l10n_uk_reports_cis module. The change ensures that binary fields now correctly accept the 'BinaryBytes' format, resolving a previous incompatibility. This ensures accurate reporting for UK tax compliance.
Original PR description
Since https://github.com/odoo/odoo/pull/244421, binary field does not accept 'bytes' but to be wrapped explicitly as 'BinaryBytes' task-5481774 Forward-Port-Of: odoo/enterprise#115249
This update corrects a mismatch in transaction identifiers used when generating financial reports (FAIA). Previously, the system used different methods for identifying transactions, leading to potential errors in export data. This change ensures all transaction IDs align, improving the accuracy and reliability of financial reports.
Original PR description
The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846
This update resolves a failing test related to WorldLine integration within our self-order point-of-sale system. The fix ensures that the test only runs if both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are installed, preventing errors and improving test reliability.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed. Forward-Port-Of: odoo/enterprise#115282
This update fixes a technical issue that caused a traceback when viewing restaurant bookings with no bookings. The fix corrects an automatic change introduced during a migration, ensuring the correct variable is accessed within the booking list view. This improves the stability and usability of the restaurant booking module.
Original PR description
Inside the custom list renderer for booking for pos_restaurant we access `this.list.records` which doesn't exist and throws a traceback when no there are no bookings. The `this.` was added automatically by a migration script for OWL3 to force this usage to target component variables. But in this case `list` is set inside the web.ListRenderer template with `t-set`. This commit will revert the automatic change for the access to and replace `this.list.records`, with `list.records` Task-[6147678](https://www.odoo.com/odoo/project/1737/tasks/6147678) Forward-Port-Of: odoo/enterprise#114589
This update fixes a minor display issue in the Helpdesk dashboard, ensuring that the 7-day average customer rating is shown as a score out of 5 instead of a percentage. This provides a clearer and more intuitive understanding of agent performance for users.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#115176 Forward-Port-Of: odoo/enterprise#109804
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, only in the Kanban view. The change ensures that contact types are consistently displayed in the user's preferred language across all views, improving user experience and data clarity. This was achieved by updating the field used to display contact information in the list view.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#115331 Forward-Port-Of: odoo/enterprise#114786
This update resolves an issue where testing custom Sign app configurations caused data conflicts. By creating unique role records for demo templates 2-6, the system now avoids overwriting configurations and provides a more accurate testing environment. This ensures consistent and reliable testing of Sign app features.
Original PR description
Before this commit, all demo templates in the Sign app shared the same global `sign.item.role` record (`sign_item_role_default`). When testing custom server actions or automations that attach configurations to a specific role, testing with demo data caused silent overrides. Modifying the automation for one demo template would overwrite the shared role record and break the automation for all other demo templates. This commit introduces unique `sign.item.role` records for demo templates 2 through 6. Template 1 retains the default role. This prevents data collisions during testing and better reflects a real-world database structure where different documents often utilize distinct roles. Task: 6128909
This update resolves an issue where invoice settlement could fail if the commercial partner information wasn't fully loaded. The fix now directly uses the partner ID from the invoice data, streamlining the process and preventing errors. This ensures smoother and more reliable invoice settlement operations.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#114927 Forward-Port-Of: odoo/enterprise#111957