Wednesday, June 3, 2026
8 changes · saas-18.4
Resolved issues and error corrections
The Italian electronic invoicing checks now only trigger when the active company is Italian and can actually send invoices through SdI. This prevents irrelevant warnings for companies outside Italy, even if a customer is configured with the Italian EDI method.
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 French PDP demo mode run without requiring authentication or two-factor verification, making demos and testing smoother. It also corrects document-sending simulation when using a Peppol user instead of a PDP user, reducing false issues during demo workflows.
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
Employee profile photos in the HR employee form now keep their natural proportions instead of appearing stretched. This improves the visual quality and consistency of employee records, especially when portrait-oriented images are used.
Original PR description
Vertical images were stretched due to changes made during the form view's redesign (a58ed7d) and after adding a fixed size (6d40ab9). We've added an `.object-fit-contain` class to fix this issue and a rounded border to make the image's aligned with other similar views. task-5418517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem in the French PDP e-invoicing module that could interfere with merging partner records. It changes how the partner verification display state reacts to company context, improving reliability without changing user-facing workflows.
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 fixes date reporting when a week crosses from one year into the next, ensuring the year and week number follow the same business-calendar logic. It prevents misleading week labels such as showing a 2026 week as belonging to 2027, improving accuracy in date-based views and reports.
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 Google address autocomplete field now displays as plain text when a form or field is set to read-only. This prevents users from editing address fields in situations where changes should not be allowed, improving consistency and avoiding accidental updates.
Original PR description
**Issue:** The `google_address_autocomplete` widget remained editable even when the view or field was set to `readonly`. **Solution:** Modified the `AddressAutoCompleteTemplate` to conditionally render the component. If `props.readonly` is true, the template now renders a `<span>` with the field value. Task~5182770 Forward-Port-Of: odoo/odoo#263829 Forward-Port-Of: odoo/odoo#260952
This update resolves an issue where a validation error incorrectly triggered when setting intrastat codes on product templates. The fix ensures the error only appears when a product template lacks variants and uses dynamic attributes, preventing unnecessary errors and streamlining the product creation process. This improves data accuracy and user experience.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update fixes an issue where negative line items in the MX CFDI tax reporting were incorrectly distributed. The change is necessary due to new features added to the module. This ensures accurate tax calculations for Mexican businesses using the CFDI standard.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)