Thursday, March 19, 2026
37 changes · saas-19.1
Resolved issues and error corrections
This update corrects a bug in the DIAN invoice processing workflow. Previously, the system could unintentionally delete original invoices, leading to data loss. The fix ensures the correct invoice document is protected during the update process, maintaining data integrity.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update resolves a technical issue where Odoo could experience errors when communicating with Sendcloud, specifically when Sendcloud didn't return expected shipping price data. The fix prevents a system crash caused by attempting to access missing data, ensuring smoother delivery processing.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#109252
This update fixes an issue where bank statement reconciliations in foreign currency journals were incorrectly using the invoice currency instead of the payment currency. This resulted in inaccurate balance conversions during batch reconciliation processes. The fix ensures correct currency conversion for improved financial reporting accuracy.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#108745
This update fixes a bug in the Odoo Studio report editor that prevented power buttons from appearing in reports. The change ensures the Studio instance correctly defines the necessary configuration, resolving a previous issue where table menu positioning was incorrect. This improves the overall usability of the Studio report editor.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#109506 Forward-Port-Of: odoo/enterprise#109012
This update resolves an issue that prevented users from copying spreadsheets within the Odoo Enterprise system. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This restores a key functionality for managing and sharing data.
Original PR description
Fix error which disabled the copy button. Forward-Port-Of: odoo/enterprise#110700 Forward-Port-Of: odoo/enterprise#110086
Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update fixes a bug where the WhatsApp API limitation was silently discarding subsequent attachments. The change ensures all uploaded files are sent, improving the reliability of file sharing within WhatsApp.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#110657 Forward-Port-Of: odoo/enterprise#107424
This update resolves an issue where the batch view in the quality control process displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the workflow for users creating and managing quality batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The solution allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update resolves a technical issue that prevented users from correctly editing transactions after multiple reconciliation lines were created. The fix skips a calculation step when multiple reconciled lines are present, ensuring accurate reporting and editing functionality. This improves the stability of the accounting module.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update resolves a performance issue in the Followup Report that was causing slow loading times in Odoo 19.1. The fix utilizes a more efficient filtering method, aligning with previous performance practices, to speed up report generation, particularly on large databases.
Original PR description
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1…
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out. This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field. While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime.
This update resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status is actively in progress, preventing this race condition and maintaining accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update corrects a technical issue in the Account Avatax module, ensuring it properly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates correctly within the Odoo Enterprise system.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update ensures that PIN codes are now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (digital wallets) because they couldn't access their PIN. This change improves the user experience and allows for seamless transactions.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462 Forward-Port-Of: odoo/enterprise#107231
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance when customers were located within the EU. The fix ensures that the 'Only intra-EU customers' check accurately identifies invoices that violate EU regulations, improving data accuracy and reducing potential reporting errors.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update resolves a technical issue within Odoo's Studio feature where view editing sometimes caused errors. The fix ensures that Studio correctly handles inherited views, preventing crashes and improving the stability of view creation. This change improves the overall reliability of the Studio tool.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#110835
This update resolves a minor issue preventing the correct display of a tour within the industry FSM report module. The fix ensures that the tour functionality operates as intended, improving the user experience for this specific reporting feature. This change does not impact other parts of the system.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection of invoices. The fix ensures the system accurately reflects the PA's state, improving invoice processing accuracy for Italian tax compliance. This change was triggered by a bug fix within the l10n_it_edi module.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#254406 Forward-Port-Of: odoo/odoo#253525
This update resolves an issue where ZATCA invoicing was incorrectly applied to ‘Settle Due’ orders in Point of Sale. The change adjusts how the system identifies these orders, ensuring that invoicing is skipped for ‘Settle Due’ transactions while maintaining correct invoicing for standard deposit flows. This prevents duplicate invoicing and simplifies ZATCA reporting for POS transactions.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252984 Forward-Port-Of: odoo/odoo#244712
This update fixes an issue where table menus would overlap or not appear when hovering over list items within table cells. The change now correctly displays table menus on list hover and prevents overflow, ensuring a smoother user experience when working with complex tables. This improves the overall usability of the HTML editor.
Original PR description
**Current behavior before PR:** - Table menu handlers could overflow into adjacent table areas when the targeted part of the table was only partially visible within the container. - When a table cell contained a list, hovering over the list element did not display the table UI menus, even though the mouse was inside the cell. **Desired behavior after PR is merged:** - Use a local overlay for the table menu to prevent overflow into adjacent cells. - Table UI menus are now correctly displayed when hovering over list elements inside a table cell. task-5353518 Forward-Port-Of: odoo/odoo#251977 Forward-Port-Of: odoo/odoo#240342
A recent update caused the copy button within the spreadsheet functionality to become disabled. This fix resolves the issue, ensuring users can now reliably copy their spreadsheets. This improvement maintains the smooth operation of a key feature for managing data.
Original PR description
Fix error which disabled the copy button. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253991 Forward-Port-Of: odoo/odoo#252977
This update ensures that phone numbers entered through the takeaway preset in the Odoo POS system are now correctly recorded on the order itself. Previously, this information was lost, making it difficult to contact customers. This fix improves order management and customer service.
Original PR description
Currently, when using the takeaway preset, the phone information filled in is not registered on the order. Steps to reproduce: ------------------- * Change restaurant setting to enable self order * Open mobile menu (make sure session is opened prior) * Select takeout preset * Place an order * Fill in all information, time, name, email & phone * Validate order * Go to the orders in the backend > Observe that the contact info does not register the phone (mobile) Why the fix: ------------ Nothing was done with the phone information so we now register it on the order. opw-6014340 Forward-Port-Of: odoo/odoo#253610
This update corrects a display issue where the batch view in the stock picking module showed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the process for users creating and managing picking batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#252630 Forward-Port-Of: odoo/odoo#249581
This update fixes an issue where the formatting of PDF quotes generated with the Din5008 localization module was inconsistent when hiding product compositions. Specifically, the section background and column alignment were misaligned. The fix adds a colspan to section names to ensure proper formatting and a more professional-looking PDF quote.
Original PR description
Steps to reproduce ================== - Install website_sale,accountant,l10n_de - Select the DE company - In the accounting settings, enable the "Show Position Column in Reports" - Go to Sales - Create a new Quotation - Select a customer - Add a product - Add a section - Click on the three dots - Click on Hide Composition - Add another section - Click on the cog menu - Click on Print > PDF Quote => The background of the first section ends before the end of the line => The columns are also not aligned Solution ======== Add a colspan of 2 to the section names opw-5427590 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252029
This update resolves an issue preventing sales users from printing quotes containing Intrastat data. Previously, access restrictions caused an error when exporting the quote to PDF. Now, users with sales permissions can successfully print quotes, ensuring accurate reporting and compliance.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and account_intrastat - Create a user with Sales rights only - Create a product with an Intrastat Commodity Code - Connect with the created user - Create a SO with the Intrastat product - Print PDF Quote **Issue:** An access error is raised while trying to access "account.intrastat.code" field. The user needs to have an Accounting group in order to access this field. **Cause:** When printing the quote, the SO is exported in a XML to be embedded in the PDF. The field is accessed at that moment. opw-5976725 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254333
A recent update to the website's job application form caused an error when users added a new file field. This fix ensures the form correctly handles the addition of this field, preventing submission failures. The issue stemmed from a change in how authorized fields are retrieved.
Original PR description
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add…
Currently an exception is generated when the user tries to submit a job application through the form. Steps to produce an error: - Install the `web_studio` and `website_hr_recruitment` modules - Add a new File field to the `hr.applicant` module with the studio. - Go to the website editor and add the form `Apply for a Job` and add the recently created field into the form and save it - An error will occur when submitting the form with the added field Error: `KeyError: 'manual'` This issue occurs because the `manual` key(attribute) is not included in the `authorized_fields` variable, which is generated by the `get_authorized_fields` method. After the recent refactoring introduced in commit [1], the code was changed to fetch only a limited set of attributes instead of all attributes, and the manual attribute was not added to this list. This commit resolves the above issue by including the `manual` attribute when retrieving model fields, which was not added in commit [1]. [1]: https://github.com/odoo/odoo/commit/bfae7140d3951bec93fb7f2e49018649045edd40 Sentry-7271118700 opw-5933992