Tuesday, June 9, 2026
35 changes · saas-19.3
Resolved issues and error corrections
This update fixes a reporting issue by now logging a specific message when a new partner is created through Google or Microsoft Calendar synchronization. Previously, all new partners received a generic message. This change provides clearer tracking of partners originating from calendar integrations, aiding in troubleshooting and reporting.
Original PR description
Before we were logging the new created partners default message. Now we log custom message indicating that this partner was created from Calendar sync. task-6177363 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#264392
This update resolves an issue where partner names with '&' characters were being incorrectly formatted for SEPA bank exports, leading to rejection by banks. The fix ensures '&' is preserved in name and address fields, aligning with industry standards and preventing export failures.
Original PR description
Problem: The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name)…
Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.
As a result, a partner named "test & test GMBH" was exported as:
<Nm>test + test GMBH</Nm>
instead of the expected:
<Nm>test & test GMBH</Nm>
This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.
Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:
- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.
- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.
Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.
ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:
Forward-Port-Of: odoo/enterprise#118897
Forward-Port-Of: odoo/enterprise#115409This update fixes a technical glitch that caused unexpected pop-ups and errors when using preset orders with time management in the restaurant POS. The issue stemmed from how the system handled merging orders, leading to outdated processes. This change ensures a smoother and more reliable experience when selecting and using preset orders.
Original PR description
pos*: point_of_sale, pos_restaurant Steps to reproduce: - Configure a preset identified by name and managed by time. - Open the restaurant POS. - Create a direct order and set a tab for it. - Return to the floor screen and create another direct order. - Select the configured preset and choose the previously created order from the order name popup. Issue: - The time slot selection popup appears unexpectedly. - Selecting a time slot triggers a traceback. Cause: - When selecting an existing order, the current order is merged into the selected order. - However, the time slot selection flow remains active for the merged order, which has already been deleted. Fix: - Exit the preset selection flow when the order is merged and deleted. Task-6032880 Forward-Port-Of: odoo/odoo#268709 Forward-Port-Of: odoo/odoo#253586
This update fixes an issue where sale order prices weren't accurately displayed in invoicing. The system was previously using product prices instead of the specific price set on the sale order line. This change ensures that users always see the correct price from the sale order, improving invoicing accuracy and reporting.
Original PR description
Steps to reproduce: - - Create a Sale Order with two sale order lines for the same product. - Set different prices on each SOL (e.g. 20 and 40). - Open the related project and go to the Invoicing tab. - Search for the Sale Order Lines. Issue: - Displayed price uses the product price instead of the SOL price. Cause: - The display name formatting used `product_id.lst_price`. Solution: - Use `price_unit` from the sale order line to show the correct price. task-5966799 Forward-Port-Of: odoo/odoo#250554
This update ensures that Cashdro payments are correctly cancelled when a payment is manually forced in the POS system. Previously, forced payments would remain in a waiting state, preventing proper cancellation. This change improves payment accuracy and prevents potential issues with Cashdro machines.
Original PR description
Since the Cashdro machine has no way for the user to cancel the payment through its interface, if a payment was forced the machine would remain waiting for a payment that could no longer be cancelled from the POS. To fix this, we now send a cancel request whenever a payment is forced. task-6276665 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268496
This update resolves an issue where invoices from certain Peppol suppliers (using a specific XML format) weren't being correctly imported. The fix automatically identifies the supplier's VAT information, creating the necessary partner records and linking bank accounts, ensuring invoices are processed accurately. This prevents import failures and data inconsistencies.
Original PR description
Some Peppol emitters carry the supplier VAT in cac:PartyIdentification/cbc:ID instead of the BIS3-standard cac:PartyTaxScheme/cbc:CompanyID. The import then extracted no VAT, the partner auto-creation not available (needs name+vat) and invoice.partner_id stayed empty. As a side effect, when the XML also carried a PayeeFinancialAccount, the bank account creation crashed with a NOT NULL violation on partner_id. Fall back on cac:PartyIdentification/cbc:ID when cbc:CompanyID is empty, so the partner is found (or auto-created) and the bank account is properly linked. Steps to reproduce: - Create a XML with the supplier VAT only in cac:PartyIdentification/cbc:ID and a cac:PayeeFinancialAccount/cbc:ID. - Upload on a purchase journal: import fails, the bill stays empty with an error in chatter. - With the fix: partner auto-created, bill filled, bank linked. opw-6148974 Forward-Port-Of: odoo/odoo#268316 Forward-Port-Of: odoo/odoo#261933
This update corrects a bug in the HR module's version calculation logic. Specifically, it fixed an error that could incorrectly identify overlapping contract periods, leading to inaccurate reporting. This ensures more reliable tracking of employee contracts and related data.
Original PR description
Forward-Port-Of: odoo/odoo#268807
This update prevents managers from overriding the assigned card for expense approvals. Previously, setting a manager on a card expense would be cleared upon approval, causing confusion and potential errors. Now, card expenses are read-only for managers, streamlining the expense approval process.
Original PR description
**Issue** If a manager was manually set on a card expense after it was created, it would be cleared when the expense was approved. **Change** Make the field readonly for card expenses, the idea is that the manager shouldn't need to approve card expenses since they are able to control them via the card itself. opw-6045587 Forward-Port-Of: odoo/enterprise#112593
This update fixes a persistent memory leak within the Odoo test suite. The issue stemmed from an unintended reference to internal Odoo environment variables, causing tests to consume excessive memory. The solution ensures proper cleanup of these references after each test run, improving test stability and performance.
Original PR description
Since [1], there was a memory leak in the test suite due to the path of `rpc._rpc`. This override was leaking the env and all services in every module sets created by hoot. In stable, we simply hook on the `after` callback to cleanup the patch, thus removing the reference to the env and services. In master, with owl3, the strategy will be to put the patch in a Plugin, which has a cleanup function that is executed automatically when the App is destroyed, i.e. after each test. [1] odoo/odoo#248852 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#268883
This update resolves a technical error that prevented users from successfully attaching PDF documents to invoices. The issue stemmed from a difference in how the system handles binary data versus base64-encoded data, specifically related to the Nilvera client's response. This change ensures invoices with PDFs can now be properly processed.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#268765 Forward-Port-Of: odoo/odoo#266718
This update corrects a bug that prevented signature requirement features from working correctly for shipments between US locations. The change adjusts the API request to accurately reflect the package-level nature of signature requirements for certain US deliveries, ensuring proper rate calculations and delivery confirmation. This resolves an error message preventing users from enabling signature requirements.
Original PR description
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create…
Issue ----- Enabling signature requirement blocks US -> US deliveries. Steps to reproduce ----- - Setup UPS - enable signature requirement - Set current company to US - Create a US Customer - Create a product with some weight - Create a SO for the product - Add UPS delivery and try to get a rate > Error: "The requested accessory option is unavailable between the selected locations." Cause ----- Depending on the type of transfer, signature is requested at shipment or package level (see the "Delivery Confirmation Origin-Destination Pairs" category of the following link) https://developer.ups.com/api/reference/shipping/appendix1?loc=en_US US50 -> US50 & Canada -> Canada is package level Everything else is shipment level By default we use 'ShipmentServiceOptions_DeliveryConfirmation' for which 'DCISType' = 1 is the correct value. https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L8902-L8911 For package level, we should use 'PackageServiceOptions_DeliveryConfirmation' for which 'DCISType' = 2 would be the expected value https://github.com/UPS-API/api-documentation/blob/b4064887ebcd9cd98085bc4cce088677c664473f/Shipping.yaml#L10410-L10421 ----- Ticket: opw-6173624 Forward-Port-Of: odoo/enterprise#117564
This update optimizes Odoo's styling process, specifically reducing the time it takes to recalculate styles in large tables like the Accounting Balances Sheets. By removing unnecessary selectors, the system now responds faster to window resizing, scrolling, and table sorting, leading to a smoother user experience.
Original PR description
Adapt selector to remove the :has value since it not needed to have the effect applied. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. This commit is a follow up of https://github.com/odoo-dev/enterprise/commit/8aa63b3c726d825e68430bb0a64a54c1b58d6af7 Note: We also fixes the scss button variable not correctly overided Forward-Port-Of: odoo/enterprise#119521
This update strengthens data security by restricting access to sensitive financial information within expense reporting features. Previously, unauthorized users could view financial data. Now, only users with accounting or invoicing permissions can see key details, improving data protection and compliance.
Original PR description
Some financial data were visible to users with no access rights through the customer to reinvoice advanced search and analytic distribution search when creating an expense. This commit ensures that these fields in customer to reinvoice advanced search are invisible if the user doesn't have sales nor accounting nor invoicing access rights, it also modifies the debit/credit/balance columns in the analytic distr bution to be visible to users with accounting or invoicing access rights only. task-5993099 Forward-Port-Of: odoo/odoo#262986
This update fixes an issue where vendor bills imported from Poland's KSeF system were not correctly accounting for discounts applied to individual items. The update now properly parses the 'P_10' XML node, ensuring accurate bill data import and compliance with KSeF regulations. This improves the reliability of financial reporting.
Original PR description
When fetching vendor bills from KSeF, the XML node "P_10" is used to indicate a discount per unit on a line. This node is currently being ignored when parsing the file. Official documentation: https://ksef.podatki.gov.pl/media/gn2kt4gl/broszura-informacyjna-struktury-logicznej-e-faktury-fa-1-wersja-anglojezyczna.pdf opw-6235460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268551 Forward-Port-Of: odoo/odoo#267235
This update changes how Odoo handles probe failures for serial devices like scales. Instead of generating error logs, a warning is now logged with detailed information. This prevents unnecessary alerts and improves the system's stability by reducing noise in the monitoring system.
Original PR description
Instead of logging an exception or an error on probe failure for serial devices, we now log a warning with stack info. This avoids spamming sentry with error logs that only are probe attempts. e.g. if the device plugged is a scale, we will probe for belgian + swedish blackbox first, causing two errors three times (as we retry 3x). see odoo/enterprise#119683 Forward-Port-Of: odoo/odoo#268796
This update adjusts the checksum associated with the scale certification process. Following a recent optimization of the scale driver to reduce error handling, this change ensures continued accurate certification verification. It's a routine maintenance update to maintain the integrity of our certification process.
Original PR description
As we updated the scale driver to reduce the amount of exception caught, we need to update the certification checksum. see odoo/odoo#268796 Forward-Port-Of: odoo/enterprise#119683
This update resolves a problem in the account module's testing process. Previously, leftover financial transactions interfered with test results, leading to inaccurate data. The fix ensures a clean test environment by canceling payments before removing transactions, preventing errors and improving test reliability.
Original PR description
The KPI provider test setup could leave some account moves behind when running with all modules and demo data installed. These leftover moves were then detected by subsequent test steps, causing incorrect numbers and test failures. This commit ensures the targeted moves are removed to provide an empty test environment. Payments need to be canceled first; otherwise unlinking the moves raises a ValidationError. [runbot-939456](https://runbot.odoo.com/odoo/error/939456) Forward-Port-Of: odoo/odoo#268151
This update introduces support for Belgian voluntary overtime within Odoo's payroll system. It allows for accurate tracking and reporting of overtime hours, including exemptions and standard rates, ensuring compliance with Belgian tax regulations (DMFA and 281.10 reporting).
Original PR description
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1) * Add salary rules and categories for voluntary overtime remuneration. * Enforce yearly thresholds through payroll parameters: * 240h for voluntary overtime exempt from ONSS * 120h for voluntary overtime subject to ONSS * Exclude voluntary overtime from employment bonus calculations and paid amount computation where required. * Include voluntary overtime remuneration in payroll calculations and DMFA declarations. * Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields. * Fix DMFA service hour computation and add payroll/DMFA test coverage. TaskID: 6275791 Forward-Port-Of: odoo/odoo#268313
This update introduces functionality to accurately calculate and report voluntary overtime hours for Belgian employees, aligning with local regulations. It includes new work entry types, salary rules, and reporting requirements for DMFA and 281.10 tax forms, ensuring compliance and accurate payroll processing.
Original PR description
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) *…
Add support for Belgian voluntary overtime in payroll, DMFA, and 281.10 reporting. * Introduce dedicated work entry types for: * Voluntary overtime exempt from ONSS/precompte (DMFA service code 81) * Voluntary overtime subject to ONSS/precompte at 150% and 200% rates (DMFA service code 1, remuneration code 1) * Add salary rules and categories for voluntary overtime remuneration. * Enforce yearly thresholds through payroll parameters: * 240h for voluntary overtime exempt from ONSS * 120h for voluntary overtime subject to ONSS * Exclude voluntary overtime from employment bonus calculations and paid amount computation where required. * Include voluntary overtime remuneration in payroll calculations and DMFA declarations. * Add dedicated 281.10 reporting support for voluntary overtime exempt from ONSS using the reserved tax form fields. * Fix DMFA service hour computation and add payroll/DMFA test coverage. TaskID: 6275791 Forward-Port-Of: odoo/enterprise#119355
This update fixes a conflict in the Contracts module's menu ordering. Previously, other modules could disrupt the intended layout of the 'Configuration' menu. By adjusting the menu item's sequence, this change ensures the Contracts menu remains in its correct position, maintaining a consistent and predictable user experience.
Original PR description
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other…
## Description of the issue/feature this PR addresses The “Configuration” menu item defined by the *Contracts* module uses a very low sequence value, causing menu ordering conflicts when other modules (e.g. [OCA](https://github.com/OCA/partner-contact/pull/2202/files)) add menu items in the same section. This affects not only external modules but also internal ones that add menu items under *Contacts*. ## Current behavior before PR When other modules add new menu items to *Contacts*, the *Configuration* menu moves out of its intended last position, breaking Odoo’s default menu hierarchy. <img width="467" height="148" alt="Behavior before PR:" src="https://github.com/user-attachments/assets/4cb6e3bb-00c0-4636-87de-c51b572dc42c" /> ## Desired behavior after PR is merged The sequence of the *Configuration* menu item is adjusted so that it always remains last, aligning with Odoo’s default menu hierarchy and avoiding friction between modules. <img width="467" height="148" alt="Behavior after PR is merged" src="https://github.com/user-attachments/assets/314c2556-5f2b-403d-af8d-ab550bff41a9" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234909
This update resolves an issue where the year calculation was incorrect when weeks spanned across years, particularly at the end of 2026. The fix ensures consistent year and week number tracking, preventing unexpected behavior and maintaining accurate date calculations for reporting and scheduling.
Original PR description
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on…
### Description of the issue/feature this PR addresses: getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days. So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1. The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week. ### Current behavior before PR: At the end of 2026, this will cause problems because the week number will run as: * 2026, week 52 (all days in 2026, OK) * 2027, week 53 (most days in 2026, last day in 2027, Not OK) * 2027, week 1 (all days in 2027, OK) ### Desired behavior after PR is merged: This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as: * 2026, week 52 (no changes) * 2026, week 53 (year is not incremented if week number is not reset) * 2027, week 1 (no changes, but year is incremented when week number is reset) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267871 Forward-Port-Of: odoo/odoo#267656
This update addresses a slow file preview issue when handling large files. Previously, users experienced a blank screen while a large file downloaded and rendered, leading to a frustrating experience. Now, a loading indicator is displayed during this process, providing immediate feedback and a smoother user experience.
Original PR description
When previewing a big file, the download might take long and the rendering might take even more time. The UI is blocked until the iframe is ready, but there is no feedback for the user. This commit adds some loading feedback until the iframe is rendered. Steps to reproduce: - Go to a Knowledge article - Upload a file with `/file` - Add a huge JSON file (~30MB) - Save - Click on the file icon => The preview opened but took ages to be displayed without giving any feedback to the user task-6014223 Forward-Port-Of: odoo/odoo#264136
This update resolves an issue where carousels would automatically cycle in edit mode, disrupting the page editing process. The fix pauses carousels when the edit mode is activated, ensuring a smoother and more reliable editing experience. This prevents unexpected focus changes and improves usability.
Original PR description
Commit [3ba3e45] paused carousels upon focus, and resumed it upon focusout. However, that behavior should be disabled in edit mode, as cycling is disabled (moving through the slides is only done manually). Otherwise, the carousel cycles and, after each slide, takes the focus, which makes editing the page a nightmare. [3ba3e45]: https://github.com/odoo/odoo/commit/3ba3e45b2ab995412e1a7ced2c46b9294dc353b8 task-6264462 Forward-Port-Of: odoo/odoo#268628 Forward-Port-Of: odoo/odoo#268046
This update resolves an issue where sponsor logos weren't loading correctly on exhibitor detail pages. The fix ensures the system uses the appropriate logo size (image_128) instead of a non-existent one, preventing placeholder images from appearing. This improves the visual presentation of our event exhibitor listings.
Original PR description
The sponsor logo was failing to load on the exhibitor detail page because the generic image widget was auto-generating a srcset with image_1920, a size that does not exist on event.sponsor (max: image_512). The browser would pick image_1920 from the srcset and receive a placeholder instead of the actual logo. Fixed by adding 'preview_image': 'image_128' to the t-options of the sponsor image widget, capping the srcset to existing image variants. there's another issue with the same fix: odoo/odoo@6bd2de2 related to: odoo/odoo@36e680f opw-6218587 Forward-Port-Of: odoo/odoo#264617
This update fixes a test that failed due to an assumption about the UoM feature being always enabled. The test now uses a reliable XMLID to identify items, ensuring stability across different Odoo builds (including single-app installations). This improves the reliability of our testing process.
Original PR description
Description of the issue this commit addresses: The test assumes uomDisplayName is always present and looks up Pack of 6 by name. In single_app builds, the UoM feature can be disabled, so the key is absent and a KeyError is raised. The name-based UoM search is also fragile. --- Desired behavior after this commit is merged: This commit stabilizes the test by using the Pack of 6 XMLID and by asserting uomDisplayName only when the UoM feature is enabled, while still verifying the quantity conversion logic for mixed UoMs. --- runbot-[939601](https://runbot.odoo.com/odoo/error/939601) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr