Wednesday, June 3, 2026
9 changes · saas-18.3
Resolved issues and error corrections
This update resolves a technical issue in the appointment scheduling system that caused incorrect interval calculations. The fix ensures accurate interval inversion, addressing potential errors in scheduling and preventing disruptions to user workflows. The change includes new tests to guarantee correct functionality across various scenarios.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. Forward-Port-Of: odoo/enterprise#107112
This update fixes an issue where the year calculation for weeks overlapping between years was incorrect, leading to unexpected results at the end of 2026. The change ensures that the year and week numbers are synchronized, resolving a potential data inconsistency and improving date accuracy. This ensures correct reporting and calculations related to time periods.
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#267656
This update resolves an issue where paying a PL supplier without a VAT ID (over 15,000 PLN) would trigger a traceback. The fix adds a check to prevent unnecessary verification creation, ensuring smoother payment processing for suppliers without VAT.
Original PR description
[FIX] l10n_pl_bank_verification: PL Supplier no VAT When a PL supplier has no VAT and a PL company tries to pay him a bill above 15.000 PLN, there is a traceback. The reason is that there was no check for partner with no VAT, a verification was created every time the field was compute. Forward-Port-Of: odoo/odoo#266878
This update resolves an issue where users would see warnings related to the Italian EDI integration even when it wasn't applicable. Now, the system only displays these warnings when the company is actually configured for Italian EDI processing, ensuring a cleaner user experience and reducing unnecessary notifications.
Original PR description
We shouldn't show warnings for `l10n_it_edi` if it's not possible to use it, even if the partner has its preferred EDI method set as `it_edi_xml`. Ticket [link](https://www.odoo.com/odoo/project.task/5985570) opw-5985570 Forward-Port-Of: odoo/odoo#267019
This update resolves issues within the French PDP (pdp) module during demo mode, specifically by bypassing unnecessary authentication steps and preventing the forced use of two-factor authentication. Additionally, the system now correctly handles document sending for Peppol users, ensuring accurate processing. This improves the stability and usability of the demo environment.
Original PR description
And don't force the totp in demo mode Also, fix the mocking of the send_documents when sending documents with a Peppol User and not a PDP one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267461
This update resolves an issue where Instagram videos weren't displaying correctly in website background blocks. The problem stemmed from an unnecessary addition of a URL parameter that was conflicting with Instagram's embed code. This fix removes that addition, ensuring Instagram videos now function as expected.
Original PR description
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is…
Steps to reproduce: =================== 1. Edit a page, add a Cover/Banner block. 2. Set its background to a video, paste an Instagram URL 3. Save and open the published page. => Instagram embed is broken (iframe shows nothing / error). Cause: ======= Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render. The unconditional append is itself a regression from the public-widget → interaction refactor in [2]. The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram. Solution: ========= remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction [1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492 [2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4 opw-6233081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267016
This update ensures that attachments related to invoices (generated from sales) are correctly detached, allowing for easier XML regeneration. A previous issue prevented these attachments from being included in bulk exports. This change maintains proper functionality for Italian businesses requiring attachments for tax reporting.
Original PR description
The feature introduced in odoo/enterprise#78429 allows users to detach attachments from moves, primarily to facilitate the regeneration and re-sending of outgoing XMLs (e.g., sales invoices) without needing to delete the original attachment. However, detaching should not apply to incoming XML attachments on bills that originate from EDI import, as these attachments are the received source document and are never regenerated by the system. Detaching them inadvertently prevents their inclusion in bulk XML exports. An exception exists for Italy: businesses need to send Tax Integration XMLs back to the SdI. In this specific case, detaching the Tax Integration XML is appropriate and ensures the bulk export finds the latest, correct attachment. Ticket [link](https://www.odoo.com/odoo/project.task/5062132) opw-5062132 Forward-Port-Of: odoo/odoo#239701
This update corrects a problem affecting how the `pdp_verification_display_state` field is calculated, specifically within the partner merge wizard. The change replaces a problematic setting with a more reliable method, ensuring accurate data processing and preventing errors.
Original PR description
The computed field `pdp_verification_display_state` uses the `company_dependent` field. This causes an issue with the partner merge wizard in saas-18.2+. This commit fixes it by using the `depends_context` instead. runbot.build.error-939449 Forward-Port-Of: odoo/odoo#267481
This update corrects a minor error in the date interval inversion function, ensuring it handles a wider range of input values accurately. The fix includes new test cases to verify correct behavior across various scenarios, preventing potential issues with date calculations.
Original PR description
The [commit] introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases. [commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c