Daily updates from Odoo
Navigate
Branch
Sunday, February 1, 2026
25 changes
2 changes
Resolved issues and error corrections
This update corrects an issue where customer claim processing incorrectly identified account moves due to shared VAT numbers, specifically when dealing with child invoices. The fix ensures accurate partner matching during claim processing, preventing missed account moves and improving claim resolution efficiency. This resolves a previous bug impacting claim processing accuracy.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105939 Forward-Port-Of: odoo/enterprise#103366
This update addresses a minor visual issue with the Peppol itsme button within the Odoo application. Specifically, the button's placement and colors have been adjusted to improve its appearance in light mode and provide better spacing around the logo. This ensures a more polished and professional user experience.
Original PR description
Add some space to the right of the logo. Fix the colors in light mode. task-none **Before:** <img width="197" height="62" alt="image" src="https://github.com/user-attachments/assets/77bdb995-5f22-4c3f-b0af-63b074b80338" /> **After:** <img width="198" height="59" alt="image" src="https://github.com/user-attachments/assets/c4a55cae-40d7-4d53-a8ff-dfb2e2143fdd" /> <img width="208" height="72" alt="image" src="https://github.com/user-attachments/assets/32173d46-c4fd-421d-ada5-9b6ce798a601" /> Forward-Port-Of: odoo/odoo#246495
1 change
Resolved issues and error corrections
This update resolves an error that occurred when disabling a company-dependent setting (like 'Snailmail') and uninstalling a module. The issue stemmed from how Odoo stored company-specific selection values, leading to comparison problems. The fix ensures correct handling of these values during module removal.
Original PR description
Currently, an error occurs when a company-dependent selection field (e.g. invoice sending method) keeps a value after the related module is uninstalled. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs when a company-dependent selection field (e.g. invoice sending method) keeps a value after the related module is uninstalled. **Steps to Reproduce:** 1. Install the Accounting app. 2. Disable 'Snailmail' from settings. 3. Send any invoice, make sure wizard Print & Send has selected "by Post" option. 4. Click on the Send button. **Error:** `AssertionError` **Cause:** Fields defined with `company_dependent=True` are stored as property fields rather than regular values. In PostgreSQL, these fields are stored as **JSONB** values keyed by company id. When a selection value is removed (e.g. during module uninstallation), it attempts to compare the JSONB column directly with a string value, resulting in an invalid comparison and triggering the error. - [1] **Fix:** Update the SQL query to extract the value for the active company using JSON operators (->>), ensuring correct comparison with the expected selection value. [1] - https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/odoo/addons/base/models/ir_model.py#L1812-L1815 sentry-6970900918 Forward-Port-Of: odoo/odoo#241248
21 changes
New functionality added to Odoo
This update simplifies product importing by introducing an 'Auto' mode that automatically detects and connects to relevant ecommerce APIs. This eliminates manual API key setup and dynamically suggests connections, streamlining the import process for product data. An error message is also included for empty URLs.
Original PR description
Added the 'Auto' option for ecommerce platform in order to have a default that searches for all public APIs and metadata. Linked to: https://github.com/odoo/website-scraper/pull/420 Forward-Port-Of: odoo/enterprise#103704
Enhancements to existing features
This update enhances the mobile signing experience by addressing layout issues and improving navigation. Specifically, it fixes jarring transitions and clarifies empty states, resulting in a smoother and more polished user flow for signing documents.
Original PR description
Before: - Several mobile screens had layout issues such as extra white space, misaligned elements, and uneven spacing. - During signing, the "Next" navigation appeared abruptly without a smooth transition. After: - Improved mobile layouts to remove unnecessary white space and keep grid alignment consistent. - Added placeholders on relevant screens (e.g. Documents folder, Authorized Users, redirect link) to clarify empty states. - Fixed transition issues when navigating between fields during the signing flow. Impact: - Provides a cleaner and more polished mobile signing experience. - Improves usability by making empty states clearer and navigation smoother. Task: 5493477 Forward-Port-Of: odoo/enterprise#105923 Forward-Port-Of: odoo/enterprise#104606
Resolved issues and error corrections
This update resolves a technical issue where a missing space in a route caused a problem with the account online synchronization process. The change ensures the synchronization function operates correctly, preventing potential disruptions to data synchronization. This is a minor fix focused on internal system stability.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update ensures the Odoo Enterprise spreadsheet functionality works seamlessly with the latest 'o-spreadsheet' release. The changes address a bug related to test failures and a protection feature was introduced to improve stability. This update maintains the core spreadsheet capabilities for users.
Original PR description
See https://github.com/odoo/odoo/pull/246458
This update streamlines the user experience by embedding key actions, like 'Create Vendor Bill,' directly into the appropriate journal folders (e.g., Purchase, Sales). This ensures users have the necessary tools readily available where they're working, improving efficiency and reducing navigation steps.
Original PR description
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type…
What: Previously, actions like "Create Vendor Bill" were only embedded in the main "Finance" folder. Now, these actions are also embedded directly into the specific subfolders for each journal type (e.g., "Purchase", "Sales"). All relevant actions are also kept in the parent "Finance" for general accessibility. The purchase actions are also added to the "Inbox" folder. Why: The previous behavior was inefficient. A user uploading a vendor bill to the "Purchase" folder would not see the "Create Vendor Bill" action. He would only see it when he is in the parent "Finance" folder. By embedding it by default this streamlines the process by ensuring the necessary tools are available exactly where the user is working. How: The logic is implemented within the _documents_configure_sync method of the account.journal model. This is the ideal location because it handles the complete setup of a journal for the Documents app. This ensures that actions are embedded correctly both during module installation and dynamically whenever a new journal is created by a user. Notes: - Tests were rewritten to check these embeddings on install. And were refactored to be more maintainable and cover bank statements better. - The test for importing bank statements had to be moved to a separate testing module, as it needs the `account_bank_statement_extract` module, which is not in the dependencies of `account_move`. - The tests for bank statement processing errors was improved to match the tests in later versions Task-5410752 Related Task-5075610 Forward-Port-Of: odoo/enterprise#105924 Forward-Port-Of: odoo/enterprise#102039
This update aligns the appointment quick create form with recent design changes for calendar dialogs, ensuring a consistent user experience. The adjustments restore icons and field alignment, improving the visual appearance and usability of the appointment scheduling process.
Original PR description
Following odoo/odoo#238855 the dialogs design have been improved. While improving the calendar dialog, the appointment one has been overlooked. Adapting the appointment quick create form following the changes in its parent calendar form view. Restoring icons and fields alignment. Task-5887839 Forward-Port-Of: odoo/enterprise#105799
This update fixes a bug that prevented automatic reconciliation of invoices and payments when the reference information was identical. Previously, the system blocked matches, requiring manual intervention. Now, the system correctly identifies and matches invoices and payments with the same reference, streamlining the accounting process.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA) Forward-Port-Of: odoo/enterprise#105878 Forward-Port-Of: odoo/enterprise#105648
This pull request resolves issues with testing related to the MRP and Work Order accounting modules within Odoo Enterprise. The changes ensure that key reports and valuation calculations are functioning correctly, improving the reliability of financial data. This update focuses on fixing test failures and enhancing the accuracy of accounting processes.
Original PR description
Forward-Port-Of: odoo/enterprise#103353 Forward-Port-Of: odoo/enterprise#98924
This update fixes a bug that previously limited document searches to a single user root. The change now allows users to search across all user roots, expanding the scope of document retrieval. This enhancement improves usability and ensures users can find relevant documents more effectively.
Original PR description
Introduced with 7994db2c, where we forgot about the click all tests that would enable all filters at once. See runbot error 237504 Task-5893183 Forward-Port-Of: odoo/enterprise#105915
This update corrects a bug where 'todo' and 'none' audit statuses on accounts were incorrectly grouped together in reports. Previously, filtering or sorting by 'todo' wouldn't properly exclude accounts with no audit status. This ensures accurate reporting and filtering of accounts based on their status.
Original PR description
When going on the balance view of a working file, when trying to sort by the status or filtering on 'todo', the audit status with no value would still be here.
To Reproduce:
- Install the demo data
- Create a working file _ Click on Status
- The To Review and nothing are not sorted
- Add a domain ("audit_status", "=", "todo")
- THe audit status with no value are still here
Forward-Port-Of: odoo/enterprise#105899This update fixes an issue where Stripe accounts could be duplicated and prevents users from needing to re-create them after initial setup. It also ensures that Stripe account URLs are correctly formatted, resolving compatibility problems with Stripe's payment processing system. This improves the overall reliability of the expense tracking feature.
Original PR description
## [FIX] hr_expense_stripe: Fix account duplication Add a transaction commit when the account is created, to ensure that even if any further action fails the stripe account is properly set on the company. This will prevent users from creating accounts every time if the account creation part succeeded ## [FIX] hr_expense_stripe: Sanitize values for webhook url Sometimes the web.base_url is the http version of the database url, where the https is properly setup. At account creation we test the https connection, and allow the creation of the account forcing https on IAP side. But when we request the links for the account, the database will still send the http version of the url, refused by stripe. This adds a sanitization of the URLs on the database side Forward-Port-Of: odoo/enterprise#105858
This update resolves an issue where invoice data wasn't being properly validated, potentially leading to inaccurate reporting. The fix ensures that all relevant IDs are checked, improving the reliability and accuracy of key business processes related to invoices and financial reports. This enhances data confidence and reduces the risk of errors.
Original PR description
https://github.com/odoo/odoo/pull/246097 Forward-Port-Of: odoo/enterprise#105767
This update resolves an issue where the Datev export process incorrectly accessed the parent tax group when a group had child tax types. The fix ensures the export accurately reflects the children within the group, improving the reliability of financial data reporting to Datev. This was identified and addressed as part of a larger workflow improvement (opw-5480918, opw-5874567).
Original PR description
Issue: Before this commit, when a tax type is group and has children, we access the parent, even though the dict has only the children Fix: as a solution, we map through the originated tax list received from the compute all function opw-5480918 opw-5874567 Forward-Port-Of: odoo/enterprise#105638
This update resolves an issue that caused errors when creating new transcription snippets in the system. The fix ensures that record IDs are properly managed, preventing exceptions during record creation and saving. Additionally, a test was updated to handle date formatting correctly, eliminating test failures.
Original PR description
This PR fixes an issues where an exception would be thrown when inserting a transcription snippet on an unsaved record. It does so by removing the resId, resModel props and only retrieving them when actually needed (when opening the full composer to send the summary). Also whennever opening the full composer, we force a save on the record to ensure proper resId. The PR also adapts `voice_transcription_plugin.test.js` to add the locale to the date that is inserted when starting a transcription, avoiding local test fails. task-5788331 Forward-Port-Of: odoo/enterprise#105771 Forward-Port-Of: odoo/enterprise#105026
This update resolves an issue where editing a bank statement line triggered unnecessary recalculations of all related lines, including reconciled ones. The change now only recalculates the specific line that was modified, improving performance and stability when working with bank statements. This ensures a smoother and more efficient user experience.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885 Forward-Port-Of: odoo/enterprise#106084 Forward-Port-Of: odoo/enterprise#105754
This update fixes an issue where embedded actions within folders were hidden from the interface, preventing users from managing or deleting them. The change ensures that embedded actions remain visible and accessible through the folder's server actions list, streamlining the process for users to manage their documents.
Original PR description
### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881 Forward-Port-Of: odoo/enterprise#105800 Forward-Port-Of: odoo/enterprise#100395
This update resolves an issue where custom role names added to sign templates weren't being saved correctly. The fix addresses a problem with how the system updated role names, preventing users from consistently seeing their desired role names. This ensures that role names entered by users are now accurately reflected within the sign template interface.
Original PR description
Currently, On renaming or updating roles in the sign template doesn't get saved due to which drag-drop 'Signature Item' is reseted back to 'Signer 1'. **Steps to reproduce:** 1) Install sign app. 2)…
Currently, On renaming or updating roles in the sign template doesn't get saved due to which drag-drop 'Signature Item' is reseted back to 'Signer 1'. **Steps to reproduce:** 1) Install sign app. 2) Open the Sign app and select a template. 3) Case A (Direct Rename): In the sidebar, rename a role from 'Signer 1' to 'Signer 1-Test'. 4) Case B (Edit Button): Click the '3-dots' button on the role and click `edit`, change the name to 'Signer 1-Test', and save. 5) Drag and drop 'Signature Item' to template. **Observed Behaviour:** - The Role is not updated as `Signer 1-Test` and reset back to `Signer 1` **Expected Behaviour:** - The Role should be updated as `Signer 1-Test`. ## **Root Cause:** ### **Case A:** The `updateSignerNames` method(see[1]) checks `if (signer.name.includes(str))` where `str` is `Signer` This condition evaluates to true for any custom name containing that substring, causing the code to overwrite the user's custom input with the default generated name string. ### **Case B:** 1) The method `updateRoleNameAndAvatar` see([2]) updated the local state `this.state.roleName` but failed to trigger the `onChangeRoleName` prop. As a result, the parent component (`SignTemplateSidebar`) remained unaware of the change and overwrote the name with its stale value during the next update cycle (triggered by the drag-and-drop action). 2) **when `sign_emsigner` module is installed:** The module patches `openSignRoleRecord` to manually set `this.state.roleName = data.name` before the role update process completes. However, `onChangeRoleName` relies on the condition `name !== this.state.roleName` to decide whether to notify the parent component (via `this.props.updateRoleName`). Since the state is already updated manually, this check fails (returns false), the parent is never notified, and the database is not updated. When `sign_emsigner` subsequently triggers a re-render (via `displayAddDocumentButton`), the parent passes down the old, state name, reverting the user's changes. ### **Fix:** 1) Remove all `updateSignerNames` logic since it is difficult to distinguish between a default-generated name and a user-customized name. 2) Update `updateRoleNameAndAvatar` to call `this.onChangeRoleName` with the new name, ensuring the parent component's state is synchronized. [1]- https://github.com/odoo/enterprise/blob/382dd07b8ef93e9315963825e69066155a534ba0/sign/static/src/backend_components/sign_template/sign_template_sidebar.js#L92-L102 [2]- https://github.com/odoo/enterprise/blob/afc32de0a2757d8f241886ce27736fb7c07ab8c7/sign/static/src/backend_components/sign_template/sign_template_sidebar_role_items.js#L121-L122 **opw-5389063** Forward-Port-Of: odoo/enterprise#102534
This update fixes a misclassification of account 649 within the French Profit and Loss report. The account was incorrectly placed in the 'Reversals' section, which is now corrected to align with French accounting standards. This ensures accurate reporting for French businesses using the Odoo Enterprise system.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves an issue where module installations would interfere with the website configuration process, specifically the trial flow. The fix ensures correct redirection to the website configurator and introduces a sequence number to prevent conflicts with other modules attempting to auto-install with tasks.
Original PR description
Fix the issue with the ir_actions_todo. The issue was that we would take over the todo of website since only one todo can be executed at the end of a module install. When we did that we didn't correctly redirect to the website configurator. Now we do and we also increase the sequence so that if another module wants to auto-install with a todo it will by default fail for them (because the default sequence is 10) rather than silently break the website (and website_genrator trial) flow. Linked to: https://github.com/odoo/enterprise/pull/104789
This update corrects a bug in how customer claims are processed, specifically when invoices share the same VAT number (like parent and child invoices). Previously, the system incorrectly selected the wrong partner during the claim update process, leading to missed account moves. This fix ensures accurate claim processing and updates.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105939 Forward-Port-Of: odoo/enterprise#103366
Code cleanup and technical improvements
This update streamlines the testing process for the Ar-EDI module by automatically verifying data against JSON files. This change allows tests to run without external dependencies and simplifies updates to test data through a simple tag. It ensures greater reliability and faster development cycles.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206 Forward-Port-Of: odoo/enterprise#105730 Forward-Port-Of: odoo/enterprise#103370
1 change
Resolved issues and error corrections
This update resolves an issue where customer claims weren't being processed correctly due to a limitation in how the system matched invoices based on VAT numbers. Specifically, when a child invoice contact shares a VAT number with a parent, the system would incorrectly select a partner, leading to missing account moves. This fix ensures accurate claim processing by handling shared VAT numbers properly.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105939 Forward-Port-Of: odoo/enterprise#103366