Daily updates from Odoo
Thursday, June 4, 2026
25 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 corrects a bug where taxes were incorrectly applied to COGS lines generated from vendor bills. The fix ensures that COGS lines, representing internal operations, are not subject to tax calculations, maintaining accurate financial reporting. This resolves a previous issue impacting tax accuracy on sales transactions.
Original PR description
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This…
Issue: After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them Steps to reproduce: 1. Turn on Anglo-Saxon accounting 2. Turn on automatic accounting 3. Make a FIFO product category and make the valuation automatic 4. Make a new product and set the FIFO product category on it 5. Make sure the product has a vendor tax set 6. Make a purchase order for 10 of the FIFO product category at $10 7. Create and validate the receipt for 10 8. Make a sales order for 6 of the FIFO product category at $10 9. Create and validate the delivery for 6 10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20 11. Edit the tax at the bottom of the total 12. Confirm the vendor bill 13. Notice that the tax at the bottom of the total changes 14. Reset the vendor bill 15. Remove the purchase tax from the product 16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time Cause: On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change Solution: Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids” opw-6110692 Forward-Port-Of: odoo/odoo#267957 Forward-Port-Of: odoo/odoo#265352
This update resolves an issue preventing users from correctly inserting dynamic fields into SMS templates within Marketing Automation. The fix ensures the system recognizes the correct data source (`mailing_model_real`) for SMS templates, allowing users to build campaigns with accurate, personalized messages. This improves the overall reliability of the SMS marketing feature.
Original PR description
The SMS template form view in Marketing Automation was missing the `dynamic_placeholder_model_reference_field` option on the `body_plaintext` field. Without this option, the dynamic placeholder hook falls back to looking for a `model` field in the record data, but `mailing.mailing` uses `mailing_model_real` instead. Steps To Reproduce: - Install marketing_automation_sms and CRM modules (also activate Leads). - Start a new Campaign in Marketing Automation. - Set Target to Lead/Opportunity. - Add New Activity > Activity Type = SMS > SMS Template = create one. - In the SMS template dialog, click the "Insert Field" button. - Error appears: "You need to select a model before opening the dynamic placeholder selector." Ticket [link](https://www.odoo.com/odoo/project.task/5488849) opw-5488849 Forward-Port-Of: odoo/enterprise#104423
This update fixes an issue where incorrect tax reason codes were being generated when using co-contractant fiscal positions. This prevented the system from properly validating invoices against Peppol standards, ensuring compliance and accurate tax reporting. The change ensures the correct tax reason code is applied, resolving a validation error.
Original PR description
When a co-contractant fisacl position is selected and the user chooses a tax that does not belong to that fiscal position, a tax exemption reason code is added, which breaks the schematron validation on peppol. related-task-id-5905176 Forward-Port-Of: odoo/odoo#266429 Forward-Port-Of: odoo/odoo#264887
This 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 resolves an issue where lengthy address fields during credit card payments via Authorize.net caused error messages. The system now automatically truncates excessively long fields to comply with the Authorize.net API requirements, ensuring smooth payment processing. This improves payment reliability and prevents disruptions for our customers.
Original PR description
Steps to reproduce: - install payment_authorize module; - complete a credit card payment using Authorize.net with more than 60 characters on any other field than first name, last name or company; - confirm the payment. Issue: An error message appears. Cause: The Authorize.net API define the max length of information. It is possible that some information exceeds the maximum length. (https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd) Solution: Truncate information if the number of character is too large. opw-6141441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262154
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 preventing Peruvian businesses from generating Closing Entries in Odoo 18.3. The change introduces a dedicated tax report variant and Return Type, ensuring accurate VAT calculations and proper accounting workflows within multi-VAT environments. This allows users to utilize Odoo's automated closing processes safely.
Original PR description
### Issue Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns The Return mechanism implies that…
### Issue Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes ### Cause The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts ### Steps to reproduce - Install `l10n_pe_reports` and `accountant` - Switch to a PE Company - Go to the Tax Report Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry ### Notes This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely enterprise-pr: https://github.com/odoo/enterprise/pull/117891 opw-5978673
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 resolves a bug that caused unexpected pop-ups and errors when using preset orders in the restaurant POS. The fix ensures that the time slot selection process correctly exits when an existing order is merged and deleted, improving the overall stability and usability of the system. This prevents disruptions during order creation.
Original PR description
pos*: point_of_sale, pos_restaurant Steps to reproduce: - Configure a preset identified by name and managed by time. - Open the restaurant POS. - Create a direct order and set a tab for it. - Return to the floor screen and create another direct order. - Select the configured preset and choose the previously created order from the order name popup. Issue: - The time slot selection popup appears unexpectedly. - Selecting a time slot triggers a traceback. Cause: - When selecting an existing order, the current order is merged into the selected order. - However, the time slot selection flow remains active for the merged order, which has already been deleted. Fix: - Exit the preset selection flow when the order is merged and deleted. Task-6032880
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 an issue where Austria POS receipts weren't printing correctly due to an incorrect offset calculation. It also prevents authentication deadlocks with Fiskaly and FON, ensuring smoother integration. The previous response was unrelated and has been removed.
Original PR description
In this task: -------------- - Fixed Austria closing receipt printing by calculating the offset from the last closed month instead of the current month. Closing records are returned in ascending order and exist only for completed months, so the latest month must use offset 0. - Prevent a deadlock during Fiskaly and FON authentication by checking for open sessions before starting any authentication flow, instead of after the first step of authentication. - The resp was used to show error which was not in the scope. task: 5420256
This change reverts a recent update that was disrupting the process of reconciling bank transactions with previous statements. It allows users to continue their standard workflow of matching current transactions with historical records. This fix ensures accurate financial reporting and avoids disruptions to user operations.
Original PR description
This reverts commit e2a9f3bfbb8a89533146f76509bf2785c085ebea as it disrupt workflow where users needs to reconcile with a previous bank transaction Enterprise PR: https://github.com/odoo/enterprise/pull/118169 opw-6230807 Forward-Port-Of: odoo/odoo#268088 Forward-Port-Of: odoo/odoo#266057
This update reverts a previous change that was causing issues with matching manual bank reconciliation operations. It resolves a bug where past manual entries weren't correctly recognized, ensuring accurate record-keeping and reporting. This improves the reliability of financial data within the system.
Original PR description
This reverts commit 038f527793757c3148b775af1657c5a70a5abc66. opw-6230807 Forward-Port-Of: odoo/enterprise#119293 Forward-Port-Of: odoo/enterprise#118169
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
This update resolves an issue where DIAN POS orders would fail with refund errors due to missing customer information. The fix ensures the 'final consumer' partner is always loaded, preventing blank customer labels and allowing refunds to process smoothly. This improves the reliability of the POS refund process.
Original PR description
When DIAN POS is enabled, l10n_co_edi_pos auto-assigns the `Consumidor Final` partner to new POS orders. However, POS only preloads a limited partner set in frontend memory. If `Consumidor Final` is not part of that set, the order gets a partner id whose full partner data is not loaded in the UI. This causes the customer label to appear blank and refund flows to fail with "Can't change customer" mentioning `undefined`. To avoid this, always include the final consumer partner in `get_limited_partners_loading()`. This matches the approach already present in newer branches. opw-6238935 Forward-Port-Of: odoo/enterprise#119321 Forward-Port-Of: odoo/enterprise#118408
This update fixes an issue where project profitability reports were inaccurate when vendor bills included negative subtotals (like downpayments). The change ensures that all analytic lines, regardless of sign, are now correctly considered in calculating project costs and profitability. This improves the accuracy of financial reporting.
Original PR description
**Problem:** If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An…
**Problem:** If a vendor bill associated with a project through its analytic distribution has lines with negative subtotals, those lines are not considered in the project profitability report. An example use case is a downpayment invoice, followed by a final invoice with the downpayment amount deducted. **Steps to Reproduce:** - Ensure project_purchase is not installed - Create a new project with "Billable" enabled - Go to the project settings and create an analytic account - Create and post a vendor bill with a line labeled "downpayment", the analytic account set, and a unit price of 5 - Duplicate the vendor bill, set the "downpayment" line unit price to -5, add a line labeled "product" with the analytic account set and a unit price of 10, and post the bill -> Go to the project updates and see that the vendor bill costs is wrong (15) **Solution:** A similar bug affecting customer invoices was resolved in PR #130992. AMLs with non-zero subtotals should be considered, so the domain is adjusted accordingly. opw-6172523 Forward-Port-Of: odoo/odoo#265378