Friday, May 29, 2026
139 changes
1 change
Resolved issues and error corrections
This update fixes issues related to text selection within the website interface, particularly around nested uncrossable elements. It ensures that selections are correctly maintained, even with complex HTML structures, and improves the overall user experience by accurately reflecting user selections.
Original PR description
*: html_editor, html_builder ### Commit 1: [FIX] html_editor, website: improve helper util setSelection and tests **Before this commit**: after the selection restriction commit…
*: html_editor, html_builder ### Commit 1: [FIX] html_editor, website: improve helper util setSelection and tests **Before this commit**: after the selection restriction commit (https://github.com/odoo/odoo/commit/d09c8fd428315b8c3bf08c43d55da50fcd77f2ae), the tests have to dispatch events specifically to mimic the selection made by mouse. **After this commit:** we improve the setSelection helper to include a flag isMouseEventSimulated and simplify the tests. task-6143995 ### Commit 2: [FIX] html_builder*: improve selection correction for nested uncrossable *: website **Before this commit:** correctSelectionOnUncrossable is not exhaustive for complex html snippets. When there are multiple uncrossable elements in the selection, and there's a parent uncrossable element including other uncrossable ones, the selection is only restricted on the parent uncrossable element. We had a fix for the select all behavior but not for mouse selection. Reproduction: - Have a blockquote snippet with some text around it - Select the text from the blockquote to the text after it => it will keep the authors info selected - And then, if I click on the text, the selection will restrict to the text without the author infos **After this commit:** We now always correct the selection on uncrossable in an iterative way, until the selection is not corrected anymore or a maximum of attempts is reached. We didn't use the loop condition like previously done. Because there can still be an uncrossable inside the selection, when the closest uncrossable elements of the focus node and anchor node are the same. Instead, we stop the looping when the selection isn't being corrected anymore. task-6143995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update fixes an issue where the calculation of the gross total on invoices wasn't accurately accounting for both line and global discounts. The change ensures the correct raw total is calculated before taxes and discounts, leading to more accurate invoice totals and improved financial reporting. This resolves a discrepancy impacting global discount implementations.
Original PR description
2 changes
Resolved issues and error corrections
This update corrects a problem with Odoo's Mexican CFDI (electronic invoice) exports. Previously, cash rounding lines were incorrectly included, causing the XML to be rejected by tax authorities (SAT). The fix ensures that only the pre-rounding amounts are reported, complying with SAT regulations and preventing export errors.
Original PR description
When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078 Forward-Port-Of: odoo/enterprise#112633
1 change
Resolved issues and error corrections
This update improves the accuracy of consolidated financial reports by ensuring that all accounts, even those without a direct code mapping, are included in the consolidation process. Previously, accounts lacking a code on the company selector were filtered out, leading to incorrect report totals. This fix ensures all relevant accounts are considered for consolidation, providing more reliable financial data.
2 changes
Resolved issues and error corrections
This update resolves an issue where orders placed via mobile self-order with 'Pay After Meal' and online payment were not being sent to the kitchen for preparation. The fix ensures that all orders, regardless of payment type, are now correctly displayed in the Preparation Display, improving order flow and kitchen efficiency. This impacts Restaurant and Self-Order modes.
Original PR description
pos* = pos_self_order_preparation_display, pos_online_payment_self_order_preparation_display Configuration: -------------- - Restaurant Mode - Self-Order Mode: "QR + Ordering" - Service At: Table - Pay after meal (Online Payment) Issue: ------ Orders created via mobile self-order using "Pay After Meal" + online payment were not appearing in the Preparation Display. Steps to Reproduce: ------------------- 1. Create an order from mobile self-order. 2. Open the restaurant POS, the order is visible there, but it does not appear on the preparation display. Cause: --------------- - The system only sent paid orders to the kitchen when online payment is set, skipping pay-after-meal case. Fix: ------------ - Updated logic to send all orders to the kitchen when “Pay After Meal” is selected, Task: 5929555
1 change
Resolved issues and error corrections
A crash in the template editor within Odoo 19.4 has been resolved. The issue occurred when users navigated back to the template list after editing a template, resulting in a blank screen. This fix ensures proper state cleanup during editor closure, improving stability and preventing disruptions for users.
Original PR description
Version: - saas 19.4 Steps to reproduce: - Open a template in the template editor - Click the Templates button to go back to the template list Issue: Clicking the Templates button while in the template editor caused a blank screen and a js crash due to incorrect state cleanup when the editor was closing. Fix: Fixed the crash by correctly clearing the editor state through the parent component instead of directly writing to a prop when the template editor closes. taskid - 6247092
3 changes
New functionality added to Odoo
This update implements a new system for French businesses to electronically report transactions (B2C and international B2B) to tax authorities. It addresses a legal requirement for structured data reporting via ‘Flux 10’, enhancing compliance and data accuracy. Security enhancements, including 2FA and KYC, have also been added to protect sensitive financial information.
3 changes
Resolved issues and error corrections
This update resolves an issue where the Profitability report's Cost of Goods Sold dashboard didn't display correctly when multiple invoices were associated with a project. The fix ensures that all related journal entries are accurately reflected, regardless of the number of invoices generated.
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact…
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines. Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10) = 98.889 This does not equal the expected outcome of $100. Expected Behavior: Based on the previous example, the formula for the calculation should be: (raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9 = 100 The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts. Steps to reproduce the issue: - Bug was encountered when implementing a global discount solution for l10n_co_dian. - Create an invoice with a product line and in-line discount and another line for global discount - Setup the base lines for the invoice and attempt the following: - _dispatch_global_discount_lines - _squash_global_discount_lines - _add_and_round_raw_gross_total_excluded_and_discount opw-5412446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266584 Forward-Port-Of: odoo/odoo#262137
This update fixes an issue where the calculation of the gross total on invoices with both line and global discounts was incorrect. The change ensures accurate gross total calculations, particularly when global discounts are applied, leading to more reliable invoice totals and improved financial reporting. This resolves a discrepancy impacting invoice accuracy.
Original PR description
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact…
Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines. Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10) = 98.889 This does not equal the expected outcome of $100. Expected Behavior: Based on the previous example, the formula for the calculation should be: (raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9 = 100 The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts. Steps to reproduce the issue: - Bug was encountered when implementing a global discount solution for l10n_co_dian. - Create an invoice with a product line and in-line discount and another line for global discount - Setup the base lines for the invoice and attempt the following: - _dispatch_global_discount_lines - _squash_global_discount_lines - _add_and_round_raw_gross_total_excluded_and_discount opw-5412446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266584 Forward-Port-Of: odoo/odoo#262137
Original PR description
When having an horizontal group with domain including two companies that share the same account codes, report lines with account codes engine don't display the two companies values when both are…
When having an horizontal group with domain including two companies that
share the same account codes, report lines with account codes engine
don't display the two companies values when both are selected in the
company selector.
Steps to reproduce:
- Install l10n_ch and create two CH companies (CH1 and CH2)
- Create an horizontal group with the field 'Company' and domain '["|",
("name", "=", "CH Company"), ("name", "=", "CH 2")]"
- Apply the Horizontal group to CH balance sheet report
- Select both companies in the company selector
- Open CH BS report and activate the horizontal group
-> Only the column of one company is filled
Fix:
https://github.com/odoo/enterprise/commit/9b775ed9d8b2a18e708219c72e95652571f3936a
was introduced in 19.0 to fix the same issue, we fix by backporting it
but we also need to backport this perf commit https://github.com/odoo/enterprise/commit/7da3123dc4487a7092deef8503a9791ceffddcfb
that refactored the code before in a first place
opw-6204601
Forward-Port-Of: odoo/enterprise#118544
Forward-Port-Of: odoo/enterprise#117103This update resolves a critical issue that caused OOM crashes when generating the Swedish SIE 4 report with large datasets. By optimizing the database query and using efficient data processing techniques, the report now runs significantly faster and uses far less memory, improving overall system performance.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#117577 Forward-Port-Of: odoo/enterprise#113227
Original PR description
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B…
France’s electronic invoicing reform : The tax administration needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C. This creates two complementary obligations: - **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow. - **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based). ## Scope Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information. Flux 10 is introduced for transactions that must be reported separately: - B2C transactions, where there is no buyer-side e-invoice exchange. - International B2B transactions, where the counterparty is outside the French domestic B2B mandate. - Payment reporting when VAT exigibility depends on collection. The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines. ## Corrections and Lifecycle Flux 10 supports both: - **Initial reports**, for the first declaration of a period. - **Rectificative reports**, when already reported data must be corrected or completed. This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted. ## Security and Eligibility This PR also enforces stronger safeguards before using PDP/PA services. - **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app. - **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure. Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform. Task-4603708
Resolved issues and error corrections
This update resolves an issue where clicking outside a table while in transfer mode incorrectly canceled order transfers. Previously, the system would silently transfer orders after a misclick, leading to a confusing user experience. Now, the transfer listener is removed immediately when transfer mode ends, ensuring clicks outside a table truly cancel the action.
Original PR description
Description of the issue/feature this PR addresses: In pos_restaurant, the document click listener used for table transfer is only removed on the success path, leaking on misclick. Regression from [29d06d76889c](https://github.com/odoo/odoo/commit/29d06d76889c) Current behavior before PR: Cashier hits Transfer / Merge, clicks somewhere that isn't a table: the "transfer ongoing" banner disappears, so the action looks cancelled. Any later click on a table silently transfers the order to it. Nasty on floorplans with many tables. Desired behavior after PR is merged: removeEventListener fires as soon as transfer mode exits, regardless of whether the click hit a table. Misclick truly cancels; cross-floor transfer (via .button-floor) still works --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the inventory counting barcode app would fail when using archived units of measure. The fix ensures that archived UOMs are correctly loaded into the inventory count cache, allowing accurate barcode scanning and count operations. This improves the reliability of physical inventory processes.
Original PR description
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments…
### Steps to reproduce: - In the settings enable: "Units of Measure & Packagings", "Storage Locations" - Create a product in units and register 1 unit in stock - Inventory > Operations > Adjustments > Physical Inventory - Select your line and request a count > Set Current Value - Inventory > Configurations > units of measures > UOM categories - Select unit and archive it - Go to the barcode app > Click Count inventory ### > Owl error: Uncaught promise ### Cause of the issue: Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error: https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110 opw-6250090
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product…
Steps to reproduce: ------------------- 1. Install `sale_project_stock` and Accounting. 2. Create a storable product with **Real-time valuation** and configure the COGS account in the product category expense account. (Ensure you have enabled automatic & analytic accounting from accounting>config.) 3. Create a project with a specific analytic account and ensure the project is billable. 4. Create a sale order with the created product and set the same analytic account in the analytic distribution. 5. Confirm the order, deliver the product, generate the invoice, and post it. 6. Open the project and go to the *Profitability* report. 7. Click on the **Cost of Goods Sold** dashboard item. 8. Repeat steps 4–7 with multiple invoices. Issue: ------ When there is only one invoice, clicking the COGS dashboard item correctly displays the related move lines. However, when there are multiple invoices, the action opens with empty results. Cause: ------ `_get_action_for_profitability_section` sets `res_id` only when a single record exists. When multiple records are present, `res_id` becomes `False`, which causes the action to open without results. https://github.com/odoo/odoo/blob/8f79d407724f40ba8e48f1747b2e87311b7fb49e/addons/project_account/models/project_project.py#L78-L83 Solution: --------- When `res_id` is not set, search `account.move` records using the domain to retrieve the relevant move IDs, then apply a proper domain to display all related COGS journal items. opw-5949261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where importing Peppol/UBL XML files with multiple embedded PDFs resulted in PDFs being split into separate invoices. The fix adjusts the system's sorting logic to ensure all embedded PDFs are correctly included within the primary invoice. This improves the accuracy of invoice data during import.
Original PR description
When importing a Peppol/UBL XML file containing multiple embedded PDFs the first PDFs is extracted in the same invoice, all the other in separate documents. Steps to reproduce: - Set up a BE Company - Import a Peppol XML with multiple embedded PDF - Check the created Bills Issue: First embedded PDF is extracted in the bill along with the source XML. Other documents are expanded in separate Bills. This occurs because the sort weight of the additional embedded document is the same, causing the system to separate them from the main invoice. opw-6231265
This update fixes an issue where taxes weren't correctly applied when using amount discounts on sales orders. The fix backports a previous resolution, ensuring that taxes are now accurately calculated and reflected on discounts, improving sales reporting and financial accuracy. This resolves a reported problem (opw-6219611) impacting sales order processing.
Original PR description
Issue: --- Tax is not mapped on amount discount line. To reproduce: 1- Create a SO. 2- Add a SOL with a tax. 3- Add a Fixed-Amount discount. As you see, no tax is mapped. This fix is a backport of the 4ea8e9f7d4755107df9a31b66ef09a75e9593b16. opw-6219611