Tuesday, May 26, 2026
12 changes · saas-18.2
Resolved issues and error corrections
This fix prevents the editor from crashing when a user removes a table while table resizing is active. It makes table editing more reliable by ignoring invalid resize actions and only starting resizing from the main mouse button.
Original PR description
#### Description of the issue this PR addresses: - Table resize listeners are not cleaned when the table is removed while resizing - Next mousemove runs resize logic with a null target and throws traceback #### Desired behavior after PR is merged: - Restrict resize start to primary mouse button only - Prevent resize logic execution on null targets #### Steps to reproduce: - Open the todo app - Insert a table and select whole table - Move cursor on a table cell border to see resize cursor - Right click and choose Cut from browser context menu - Move the mouse again - Resize logic crashes with null target traceback task-6212279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264065
This fixes an issue where translated website placeholders could show raw formatting markup instead of readable text, such as when editing a translated blog title. Business users translating website content will now see clean placeholder text, making the editing experience clearer and more professional.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#265575 Forward-Port-Of: odoo/odoo#263320
This fixes an issue where Spanish purchase bills using the agriculture VAT regime could be rejected when sent through TicketBAI. The correct tax regime code is now used for purchase bills, helping affected companies submit compliant electronic invoices without validation errors.
Original PR description
…hase bills **STEP TO REPRODUCE** 1. Create a bill with a invoice line with a regimen agricultura tax. 2. send the bill using TicketBAI. 3. You will get the following error: Error:cvc-enumeration-valid: Value '19' is not facet-valid with respect to enumeration '[01, 02, 03, 04, 05, 06, 07, 08, 09, 12, 13]'. It must be a value from the enumeration. opw-6200686 Forward-Port-Of: odoo/odoo#265785 Forward-Port-Of: odoo/odoo#264037
This fix prevents an error when users create Brazilian bank accounts with an empty Pix proxy value. It improves reliability by showing normal validation behavior instead of causing a system traceback.
Original PR description
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts >…
Creating a bank account with a falsy proxy value generates a traceback. Steps to reproduce the error: - Install ``l10n_br`` module with demo data - Switch to BR Company - Go to Contacts > Configuration > Bank Accounts > Create a new bank account > Add any value as Account Number > Account Holder: BR Company > Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save Traceback: ```py InvalidFormat: The number has an invalid format. ``` ```py TypeError: 'bool' object is not iterable ``` https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45 For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value raises a traceback. https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61 For ``Random Key`` validation, ``re.fullmatch`` expects a string value, but receives ``False``, leading to a traceback. sentry-7488238698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264995
Link preview records now show a friendly label instead of an internal technical reference. New records display as "New", and saved records use their source URL, making the technical settings area easier to understand.
Original PR description
**Problem:** Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard…
**Problem:**
Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard "New" label.
**Steps to reproduce:**
1. Settings / Technical / Discuss / Link Previews
2. New
3. Observe the breadcrumb
**Current behavior:**
The breadcrumb displays `mail.link.preview,<id>`.
**Expected behavior:**
The breadcrumb should display "New" until the record is saved, and the source URL once saved.
**Cause of the issue:**
The model defines no `name` field and does not set `_rec_name`, so the default `_compute_display_name` falls into its fallback branch and returns `f"{record._name},{record.id}"` — exposing the technical reference in the breadcrumb both for unsaved records (`NewId_...`) and saved ones.
**Fix:**
Setting `_rec_name = 'source_url'` lets the standard display name machinery compute a meaningful label from the existing required field. Unsaved records then surface the standard "New" placeholder via the web client and saved records surface their URL, without introducing a redundant `name` field or overriding the compute.
opw-6095012Fixes an issue where updating a recurring Google Calendar event by adding an attendee and changing the time could create repeated server log errors in Odoo. This makes calendar synchronization more reliable and reduces noise for administrators without changing the user workflow.
Original PR description
When a recurrence is updated in Google Calendar simultaneously with a new attendee and a changed start time, Odoo silently logs MissingError during the post-commit Google API callback Steps to reproduce: 1. Have a recurring event already synced between Odoo and Google Calendar 2. In Google Calendar, open the recurrence and edit "all events": - Add a new attendee - Change the start time 3. Trigger a Google Calendar sync 4. MissingError exceptions appear in server logs, one per event in the recurrence opw-6024835 Forward-Port-Of: odoo/odoo#265247
This fix aligns Polish electronic invoice exports with the latest legal schema rules. It avoids sending unnecessary currency-rate data for PLN invoices and ensures specific invoice flags use the only accepted value, reducing the risk of rejected e-invoices.
Original PR description
Legal ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf
- KursWaluty is optional and doesn't need to be included if it's the same as PLN.
- The following flags accept only "1" as a valid value.
See their type being etd:TWybor1:
http://crd.gov.pl/wzor/2025/06/25/13775/schemat.xsd
http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2020/07/06/eD/DefinicjeTypy/ElementarneTypyDanych_v7-0E.xsd
```xsd
<xsd:simpleType name="TWybor1">
<xsd:annotation>
<xsd:documentation>Pojedyncze pole wyboru</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:byte">
<xsd:enumeration value="1"/>
</xsd:restriction>
</xsd:simpleType>
```
Forward-Port-Of: odoo/odoo#262462This update corrects a display error in the employee attendance Gantt view. Specifically, it resolved a situation where public holidays weren't correctly marked, allowing employees to potentially work during those times. The fix involved standardizing time zone calculations to ensure accurate holiday representation.
Original PR description
[FIX] hr_attendance_gantt: fix gantt view with public holidays Bug reproduction: 1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026 2 -…
[FIX] hr_attendance_gantt: fix gantt view with public holidays
Bug reproduction:
1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)
Bug cause:
1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.
Bug solution:
1 - I converted the timezone to UTC to solve the problem.
task - 6067070
Forward-Port-Of: odoo/enterprise#112493This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module, particularly on databases with extensive sales order data. By ensuring newly created fields default to null during installation, the module now handles large datasets more efficiently and reliably.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118008
This update resolves an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key data fields like 'Folio' and 'Serie'. Swapping these values ensures the documents comply with Mexican regulations and prevents generation of invalid invoices. This change does not impact existing, valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738 Forward-Port-Of: odoo/enterprise#116955
This update ensures that service sales from European companies to Northern Ireland are correctly excluded from the EC Sales List report. This change aligns with regulations and accurately reflects sales transactions. The update was specifically developed for the Belgium localization to accommodate the handling of tax tags instead of taxes.
Original PR description
…in EC Sales List The services sales done from a european company to a Northern Ireland company should not be included in the EC Sales List Report. It should however be the case for goods and triangular transactions. test is added in Belgium localization because only localizations have handlers using tax tags instead of taxes, and services/goods/triangular sales distinction can be made with these. task-6007931 Forward-Port-Of: odoo/enterprise#117754 Forward-Port-Of: odoo/enterprise#110007
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the Kenyan Revenue Authority (KRA) eTIMS system. The fix ensures invoice descriptions are trimmed to the 200-character limit required by eTIMS, preventing submission errors and guaranteeing accurate tax reporting. This improves compliance and avoids potential delays.
Original PR description
The eTIMs specification limit the `itemNm` to 200 characters, so truncate the invoice line description to that limit to ensure that the invoice can be correctly submitted eTIMS server. Otherwise it will be rejected with: ``` Error sending to the KRA: - Request parameter error[<ItemList><itemNm>: length must be between 0 and 200] ``` Task-Id: 5220129 Forward-Port-Of: odoo/enterprise#118152