Tuesday, October 14, 2025
6 changes · 19.0
Enhancements to existing features
The account merge process now gathers existing account codes in one database operation instead of checking each company one by one. This reduces waiting time when merging accounts, especially in databases with many companies.
Original PR description
The merge wizard needs to collect the account codes of the accounts we are merging in order to write them on the merged account as the final step of the merging process. At the moment, collecting the account codes is done in Python and loops over all the existing root companies, retrieving the code of the account for each company. On a recent l10n [runbot](https://runbot.odoo.com/runbot/build/90542336) (with 146 companies), this was causing the merging step to take ~4.5 seconds per account, most of this time being taken just by collecting the account codes. Instead, we collect the codes in a single SQL query. Flamegraphs: [before.json](https://github.com/user-attachments/files/22726956/before.json) [after.json](https://github.com/user-attachments/files/22726960/after.json) task-none Forward-Port-Of: odoo/odoo#230158
This update improves performance when editing website and email content by avoiding unnecessary page recalculations. Users should notice smoother behavior in areas that update many page elements, such as the website builder, HTML editor, and product variant previews.
Original PR description
The goal of this commit is to improve performance when using setAttribute. Using the native setAttribute causes the layout to be recalculated each time it is used, even if the same value is set. We are therefore introducing the setAttribute utils, which will check that the value is different before applying it. These performance issues are noticeable in situations where many elements need to be modified. 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
Point of Sale orders received through Urban Piper can no longer be manually deleted. This helps keep online order records consistent with the normal cancellation or rejection process handled by the delivery aggregator or restaurant.
Original PR description
Before this commit: =================== - We were able to delete online orders, but generally, online orders are either cancelled by the aggregator or rejected by the restaurant. After this commit: ================== - Online orders can no longer be deleted. Task: 496669
The link editing popover now gives clearer visual feedback when users move through fields and buttons with the keyboard. Focus also stays inside the popover while tabbing, making link editing easier and more accessible.
Original PR description
Steps to Reproduce: - Select a word in the editor. - Press Ctrl + K and Enter to open the link popover. - Use the Tab key to move between the fields and buttons. Current behavior before PR: - It was not clear which field had the focus. - The border was always overridden by the `border-dark-subtle` class with `!important`, so users had no visual feedback when tabbing. - When tabbing, focus could escape the link popover instead of looping inside it. Desired behavior after PR is merged: - Inputs and selects now use the correct border color on focus, aslo discard button changes opacity when focused. - The link popover traps focus: pressing Tab/Shift+Tab will cycle through focusable elements without leaving the popover. task-4965566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223868
Odoo now identifies Peruvian customers subject to withholding rules and adds the required retention reference to the electronic invoice XML. This helps companies selling to withholding agents stay compliant with Peru's electronic invoicing requirements while keeping invoice totals calculated correctly.
Original PR description
Some customers in Peru are considered "agentes de retención", and as such have special considerations that are necessary. We must perform specific actions when working with these customers, when selling to them we must: - recieve a specific document from the customer (A followup task will add this support for companies to generate this document) - Include a retention reference in our XML. This is represented as a specific `AllowanceCharge` node that is the sum of all of the Withholding taxes on the lines with the specific code of 62. We know an invoice is to a withholding customer because all lines must have a tax that is a part of the withholding tax group. This withholding tax is not included in the monetarytotals, tax totals, or invoice line values. And there can be only one AllowanceCharge node per invoice, not one per line. task-4989463 Forward-Port-Of: odoo/enterprise#94504
The Peru localization now includes the required withholding tax and tax group by default. This helps identify customers who are withholding agents and supports accurate invoice XML generation in related enterprise features.
Original PR description
Withholding taxes are required to indentify if a customer is a withholding agent. This PR introduces the tax and tax group for the enterprise PR that will generate the changes for the Invoice XML. task-4989463 Forward-Port-Of: odoo/odoo#226684