Thursday, June 4, 2026
14 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where the cursor position was incorrect after moving content within the HTML editor. Now, when moving a table or paragraph, the cursor automatically adjusts to the start of the moved content, preserving the user's selection and ensuring a smoother 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 Forward-Port-Of: odoo/odoo#266419 Forward-Port-Of: odoo/odoo#264264
This update fixes a technical problem in Odoo's internal tools that could occasionally cause errors when copying data sets. The change utilizes a more reliable method for copying dictionaries, preventing issues related to Python's garbage collection process. This ensures data integrity and stability.
Original PR description
In Python 3.14, iterating over weak references (like `transaction.envs`) can trigger a `RuntimeError: dictionary changed size during iteration`. This happens mostly because the Garbage Collector can remove a weakref while `OrderedSet.copy()` is rebuilding the set via `dict.fromkeys()`. Instead of re-initializing the set by iterating over its elements, we now directly use the dictionary's native `.copy()` method. This atomic operation prevents the GC from modifying the size of the underlying `_map` during the copy. Forward-Port-Of: odoo/odoo#267947
This update resolves a technical issue flagged by Pylint, a code analysis tool, within the tests for our French localization module (l10n_fr_pdp). The fix ensures our code meets quality standards and prevents potential errors during development. This ensures the continued stability and reliability of the French-specific features.
Original PR description
```
FAIL: TestPyLint.test_pylint
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/test_lint/tests/test_pylint.py", line 109, in test_pylint
self.fail(f"pylint test failed:\n\n{r.stdout}\n{r.stderr}".strip())
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: pylint test failed:
************* Module l10n_fr_pdp.tests.test_partner
function already defined line 134 (E0102) at odoo/addons/l10n_fr_pdp/tests/test_partner.py:152
--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
```
runbot.build.error-939452
Forward-Port-Of: odoo/odoo#267472This update resolves an issue preventing accurate order data synchronization from Point of Sale systems. The fix corrects a typo and updates the system to check for 'done' invoicing status instead of 'invoiced,' ensuring reliable data transfer between POS and the core Odoo system. This improves the overall accuracy of order information.
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 Forward-Port-Of: odoo/enterprise#105839
This update fixes an issue where the Balance Sheet report's XLSX export was incorrectly including all accounts instead of the selected one when changing date filters. The fix removes a filtering step that was unintentionally introduced, ensuring the report accurately reflects the user's chosen account selection.
Original PR description
Steps: - Open Balance Sheet report and unfold lines - Open the General Ledger from a line with an account - On GL report, change date filter - Export XLSX report -> We export all accounts instead of the one selected in the search bar Cause: Since f8dceec74e44ffe4aef67655be8811c96da91eba we filter out the filter if a default account is defined in the context which is the case in the `caret_option_open_general_ledger` method Fix: Remove the filtering as the behavior that was fixed by the mentioned commit does not happen anymore. opw-6234427 Forward-Port-Of: odoo/enterprise#119156
This update resolves a visual bug where color selections within the HTML editor's collapsed mode weren't consistently applying. The fix adjusts how the selection is positioned, preventing the browser from reverting the color and ensuring accurate color application when editing text.
Original PR description
Steps to Reproduce: - Apply color on a collapsed selection in mobile - Type some text - Change color from the color picker Description of the issue: - The color picker closes, but the selected color is not applied. Cause: - The color was being applied correctly, but the selection was positioned at offset 0 of the newly created font node. As a result, the browser normalized the selection back to the previous font node, making it appear as though the color was not applied. Solution: - When applying color on a collapsed selection, set the selection offset to 1 instead of 0. This prevents browser normalization and keeps the cursor inside the newly created font tag, ensuring the color is applied correctly. task-6201171 Forward-Port-Of: odoo/odoo#265438
This update corrects a calculation error in the executive summary report, specifically related to the period length. Previously, the report was incorrectly calculating the number of days between dates, leading to inaccurate metrics like Average Debtor Days. This fix ensures the report accurately reflects the actual period length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#118953
This update resolves an issue where enabling the 'Sales Credit Limit' setting in the Accounting module would trigger an access error when creating new users. The problem stemmed from a default value being incorrectly applied to a restricted field due to inheritance from the 'partner' model. This fix ensures proper access controls are enforced during user creation.
Original PR description
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An…
# How to reproduce - Install the Accounting module - In the settings, enable "Sales Credit Limit" - Remove the Accounting access rights of the current user - Try to create a new user # The issue An access error is raised on the field `credit_limit` # Cause Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518 When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users` inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error. # Proposed solution Back port of this commit : https://github.com/odoo/odoo/pull/267193 Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150 opw-6240494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical detail in the Odoo Enterprise spreadsheet functionality. A recent change in the underlying spreadsheet library required updating the names of certain properties used by the composer interface. This ensures the spreadsheet component continues to function correctly and reliably.
Original PR description
Since https://github.com/odoo/o-spreadsheet/pull/6063, the props name for cellCorner have been changed to use kebab-case.
This update prevents Odoo from crashing when the Barcode Lookup API returns a broken image URL. Previously, an invalid URL would cause an error. Now, the system safely ignores these errors, ensuring the 'Get Pictures from Barcode Lookup' action continues to function without interruption.
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**
Forward-Port-Of: odoo/enterprise#116925This update resolves an issue where the system incorrectly blocked sending invoices to 0225 Peppol EAS partners. Previously, this was only allowed when the French localization module (`l10n_fr_pdp`) was installed. Now, it's enabled by default, resolving a previous demo data installation problem and ensuring broader Peppol integration.
Original PR description
Previously we blocked the 0225 peppol_eas when `l10n_fr_pdp` is not installed. But you should still be able to send to 0225 partners with just peppol. Since the PDP module is auto installed with the French localization and we block the 0225 EAS server side on the peppol (non-PDP) server it should be fine to just allow it for everyone. It also caused an issue when installing the demo data for the `hair_salon` industry in a French company on trial. opw-6268629 Forward-Port-Of: odoo/odoo#267993
This update resolves two key issues related to HR document attachments. Previously, attachments were created in the root employee folder, which was inconvenient. Now, attachments are correctly created within the appropriate HR document folders for leave and contracts. This ensures attachments are organized and easily accessible.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811
This update resolves an issue where setting a non-numeric value for the 'next check number' in bank journals would cause an error. The change ensures the system validates that the number is numeric before attempting to convert it, preventing the error and allowing users to correctly set check numbers.
Original PR description
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to…
Currently, an error occurs when a user sets a non-numeric value as the journal's next check number. **Steps to Reproduce:** - Install the `account_check_printing` module with demo data. - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`. - Open the `bank journal`. - In the `Outgoing Payments` tab > Enable `Manual Numbering`. - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`. `ValueError: invalid literal for int() with base 10: 'FA1234'` After [this commit], the next check number is converted to an integer without first validating that it contains only numeric characters [1]. Since the value can be non-numeric, converting it directly to an integer raises the error. This commit ensures that the next check number is converted to an integer only after verifying that it contains numeric characters only. [this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4 [1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61 sentry-7498755988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266280
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 accessed and displayed, improving the user experience. It's a follow-up to previous related tasks.
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#119188 Forward-Port-Of: odoo/enterprise#117229