Wednesday, June 3, 2026
10 changes · saas-18.2
Resolved issues and error corrections
This fixes how Odoo labels calendar weeks that cross from one year into the next. It ensures the displayed year matches the week number, preventing confusing reporting or scheduling labels around New Year, such as incorrectly showing 2027 week 53 instead of 2026 week 53.
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
The Italian e-invoicing module now only shows SdI sending warnings when the active company is Italian and can actually use that service. This avoids confusing alerts for non-Italian companies whose customers may still have Italian EDI set as a preference.
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 fix lets demo mode bypass authentication and one-time password requirements for French PDP e-invoicing flows, making demos easier to run. It also corrects document sending simulation when using a Peppol user instead of a PDP user, reducing demo and test inconsistencies.
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 fixes an issue that could disrupt the partner merge wizard when French PDP verification status was involved. It changes how the status is calculated across companies, helping partner records merge reliably in affected databases.
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 fix makes an automated invoice workflow wait briefly after a product is selected so the product is fully added before the next step begins. It reduces intermittent test failures and helps keep invoice product-entry checks stable.
Original PR description
When a product is selected from the kanban view, the tour sometimes returns to the invoice form before the product is fully added. As a result, the invoice line is not created and the `.o_field_product_label_section_and_note_cell` element is missing from the table, causing the next tour step to fail. Add a short delay after selecting a product to ensure it is fully added to the invoice before proceeding with the following steps. runbot-238400
This update corrects a flaw in the appointment scheduling system that caused incorrect interval calculations. The fix ensures accurate interval inversion, addressing potential issues with date ranges and improving the reliability of appointment scheduling. New tests have been added to verify this correction.
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 ensures the growth comparison percentage calculation remains consistent regardless of the period order selected in reports. Previously, the calculation was sensitive to changes in period order due to outdated assumptions about data sorting. This fix improves the reliability and predictability of financial reporting.
Original PR description
The feature had originally been implemnted at a time where the period_order couldn't be modified, and always corresponded to what we call 'descending' now. Because of that, we assumed the column at index 0 was always the most recent period ; which caused the growth comparison percentage to change when switching period order. Forward-Port-Of: odoo/enterprise#118835
This update prevents Odoo from crashing when a product's barcode lookup returns a broken or missing image URL. The fix ensures that invalid URLs are gracefully handled, avoiding RPC errors and allowing users to continue using the product image functionality. This improves stability and user experience.
Original PR description
[FIX] product_barcodelookup: avoid crash on invalid image URLs **Steps to Reproduce:** - Install Sales module. - Configure a valid Barcode Lookup API key. - Create a product without an image. - Set a…
[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
- Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
(e.g. `8426904171073`).
- Select the product and trigger the server action:
`Action -> Get Pictures from Barcode Lookup`
Issue:
**During image fetching:**
- Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
- `_get_image_from_url()` assumes the response is always a `requests.Response`
object and directly accesses: `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`
**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
- `requests.Response` for successful requests
- `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
response attributes.
**Solution:**
- Make barcode_lookup_request() always return a One Response
object.
- Move the response validation to the callers instead of returning custom
dict objects.
**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.
**OPW-6200749**This update resolves a problem where users accessing archived documents through certain methods (like widgets or direct URLs) would incorrectly display a 'not found' message. This fix ensures that archived documents are correctly displayed, improving the user experience when accessing older records. It's a follow-up to previous improvements related to document handling.
Original PR description
When a user tries to access an archived document via * a many2one widget * `/odoo/documents.document/<id>` * a discuss notification they end up in "All" with a toast specifying that the document was not found. Follow-up of Task-6068437 (follow up of Task-5386466). Task-6214488 Forward-Port-Of: odoo/enterprise#117229
This update resolves an issue preventing accurate order data synchronization from Point of Sale (POS) systems. The fix corrects a typo and updates the system to correctly identify invoices as 'done' rather than 'invoiced', ensuring reliable data transfer. This improves the integration between POS and accounting systems.
Original PR description
In this commit: - Update `read_pos_data` to check `done` state for invoicing instead of `invoiced` state - Load `account.move` model instead of `account_move` (fix typo) Task-5887318