Tuesday, May 26, 2026
11 changes · 18.0
Resolved issues and error corrections
This update resolves a bug where double-clicking an image in the Media Dialog triggered multiple actions, leading to performance issues. A simple flag has been added to ensure that the media flow is only processed once during a single click event, improving the user experience.
Original PR description
Before this commit: When double-clicking an image in the Media Dialog, the onClickAttachment method was executed twice, causing the media flow to be processed multiple times. After this commit: The issue is fixed using a boolean flag: isProcessingClick. Initially, the flag is set to false. When the first click starts, it is updated to true. If another click occurs during the same flow (e.g during a double click), isProcessingClick is already true, so the function immediately returns and prevents the action from being executed multiple times. task-6033320
This update resolves an issue where error handling for API responses was failing due to inconsistencies in how the Requests library parses JSON data. By adjusting the error handling, the system now reliably catches and manages potential JSON parsing errors, ensuring smoother operation of Odoo's integrations.
Original PR description
The requests library uses different libraries to parse json objects depending on whether or not the simplejson library is installed (https://github.com/psf/requests/blob/dc9dbdfb3434c6e58d48fd102f93e5342308817e/src/requests/compat.py#L74). This in turn causes our try/excepts to fail if the simplejson library is installed in the env we simply re-raise the json error in case the simplejson library is installed so our try/excepts flows are not broken by the existence of a random package opw-6150349 Forward-Port-Of: odoo/odoo#264303
This update fixes a visual issue in the project Kanban view where status colors weren't rendering correctly due to a mismatch between the frontend and stylesheet. The fix ensures that project updates are displayed with the intended color codes, improving the user experience.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106 Forward-Port-Of: odoo/odoo#256023
This update fixes a technical issue where Odoo experienced errors during Google Calendar synchronization when recurring events were modified with new attendees or start time changes. The fix prevents silent errors from appearing in server logs, ensuring smoother and more reliable synchronization of events between Odoo and Google Calendar. This improves the overall stability of the integration.
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 update resolves an issue where foreign currency amounts in reports (Partner Ledger, General Ledger) weren't consistently displaying the currency code in the exported XLSX files. The fix ensures the 'Currency Code' column is always included after the 'amount_currency' column, regardless of the report generation method, improving report accuracy and clarity.
Original PR description
Step to reproduce: 1. Generate an invoice with a foreign currency (different from the company currency) 2. Go to ‘Partner Ledger’ or ‘General Ledger’ 3. Export the XLSX The bug happens because in the function _add_xlsx_currency_codes_columns we did not take into account dynamic lines. With this fix, a column ‘Currency Code’ will be added after the column ‘amount_currency’ if such column exists in the report, no matter the engine used to create the lines. opw-6150600
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a node (like a table), the cursor automatically adjusts to the start of the moved content, preserving selections within the moved node. This ensures a smoother and more intuitive editing experience.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the default URL code for new languages didn't always align with existing configurations, causing errors during database upgrades. The fix ensures that if an ISO code conflicts with a pre-defined URL code, the system now uses the language's 'code' field as the default, preventing these errors and maintaining proper language setup.
Original PR description
Steps to reproduce the issue: 1. Create a fresh DB 2. Remove the language `base.lang_es` 3. Upgrade the `base` module This would throw an error because, when recreating the record, the default value for the `url_code` field is [taken from the `iso_code` field], which is `es` in this case. However, the `es` url_code is the value defined for `base.lang_es419` [here]. Proposed fix: When creating a new language, check if the `iso_code` would create a conflict with an existing `url_code`. If so, use the `code` field as default. [taken from the `iso_code` field]: https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/odoo/addons/base/models/res_lang.py#L337-342 [here]: https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/odoo/addons/base/data/res_lang_data.xml#L3
This update resolves inconsistencies in HTML parsing caused by recent updates to libxml2 and lxml. Specifically, it ensures consistent HTML output across different versions, improving the reliability of how Odoo renders web pages. This change also enhances error handling for type checking related to lxml and libxml2.
Original PR description
## [FIX] core: lxml compatibility v2.14.0+ (HTML parsing) In version 2.14.0, libxml2 fixed a long standing quirk in its HTML handling where it always implies `<p>` start tags [1]. As a result, there…
## [FIX] core: lxml compatibility v2.14.0+ (HTML parsing) In version 2.14.0, libxml2 fixed a long standing quirk in its HTML handling where it always implies `<p>` start tags [1]. As a result, there is a difference in behavior between pre and post 2.14.0 produced HTML when no start tag is provided: - pre: always has a `<p>` tag - post: depending on the case, could have either a `<span>` or `<p>` tag. This commit introduces a monkeypatch of the lxml's HTML parser when built with libxml2 2.14.0+ to maintain a similar behavior with older versions. [1]: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8cf6129bbd836e666e7eda8c9e61c00387ae388b ## [FIX] base,l10n_it_edi: catch TypeError/ValueError for lxml 6+ compat Updates exception handling to account for stricter type checking introduced in lxml 5/6 and libxml2 2.12+. Note: Ubuntu 26.04 (Resolute) provides lxml 6.9.2/libxml2 2.15 while Debian Trixie has lxml 5.4.0/libxml2 2.9.14. Don't be fooled by the version `2.12.7+dfsg+really2.9.14-2.1+deb13u1` which actually means that Debian has reverted/held back the core engine to 2.9.14 while adding commits from 2.12.7. Forward-Port-Of: odoo/odoo#259348
This update resolves an issue where deleting an action linked to an inactive user-defined filter would sometimes fail. The change ensures that inactive filters are also removed during the action deletion process, preventing data inconsistencies and improving overall system stability.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where generated PDF invoices were missing item reference information. The change ensures that all product lines display the correct internal item reference, improving invoice accuracy and clarity. This resolves a problem with vendor bills generated by external systems.
Original PR description
Some XML vendor bills generated by external ERPs were missing the Description tag, which typically contains both the [ITEM_REF] and ITEM_NAME. As a result, product lines in the generated PDF could appear without the internal item reference. This commit ensures that the item reference is always included in the displayed product line. task-6080328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where invoices with excessively long item descriptions were being rejected by the eTIMS system. The fix truncates the description to meet the 200-character limit specified by eTIMS, ensuring successful invoice submission and compliance. This prevents potential delays in receiving VAT refunds.
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