Wednesday, September 23, 2026
12 changes · saas-19.1
Enhancements to existing features
This update speeds up the setup of Argentine localization report tests by creating sample invoices more directly. It reduces test runtime and database queries while keeping the report results unchanged, helping development and release validation run more efficiently.
Original PR description
The use_current_date=False branch of _create_test_invoices_like_demo built 18 invoices through Form, which reruns the whole move onchange for every field of every line. It was two thirds of the l10n_ar_reports class setup. Create them with _create_invoice from the fields the Form set, like the other branch does. The accounting date is now the invoice date on every invoice, the report output is unchanged. With the l10n_ar_reports counterpart: | l10n_ar_reports, runbot 18.0 L10n | before (3 builds) | after | |------------------------------------|-------------------|-------| | TestArReports setUpClass | 78-103s | 31s | | module test time | 80-106s | 33s | | queries | 45.4k | 28.4k | Forward-Port-Of: odoo/odoo#290111
The Vietnam chart of accounts now includes dedicated accounts for revenue and costs from selling or liquidating investment property. This supports compliance with Circular 99/2025/TT-BTC and helps report these gains or losses separately in Profit & Loss statements.
Original PR description
Circular 99/2025/TT-BTC adds a dedicated Profit & Loss line for gains/losses on the sale and liquidation of investment property, computed from dedicated sub-accounts rather than the main revenue and cost-of-goods-sold accounts. Add the two accounts to the chart of accounts: - 5117 Revenue from sale and liquidation of investment property - 6327 Cost of sale and liquidation of investment property Task-6518304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287572
This update changes how sample vendor bills are prepared for Argentine reports tests, avoiding a slower setup method. It reduces test preparation time and database queries while keeping the report results unchanged.
Original PR description
Same as the l10n_ar fixture: the 10 demo vendor bills were built through Form, rerunning the whole move onchange for every field of every line. Create them with _create_invoice from the fields the Form set. The accounting date is now the invoice date on every bill, the report output is unchanged. With the l10n_ar counterpart: | l10n_ar_reports, runbot 18.0 L10n | before (3 builds) | after | |------------------------------------|-------------------|-------| | TestArReports setUpClass | 78-103s | 31s | | module test time | 80-106s | 33s | | queries | 45.4k | 28.4k | Forward-Port-Of: odoo/enterprise#132697
Automatic payment reconciliation now matches payment references with invoice names even when uppercase and lowercase letters differ. This reduces manual reconciliation work and helps payments be matched correctly when bank references use different formatting.
Original PR description
Currently, when a payment reference isn't in the same letter case as the invoice name, it wouldn't automatically reconcile. task-6562440 Forward-Port-Of: odoo/enterprise#131418
Resolved issues and error corrections
The website project form processing has been cleaned up and reorganized to support more reliable handling and easier future updates. This is a minor internal fix that helps maintain the feature without changing the visible user experience.
Original PR description
Clean up and move some of the form processing logic for future updates opw-6560036 Forward-Port-Of: odoo/odoo#287697
This pull request fixes several issues in Odoo's automated web testing tools and related test data. The changes help developers catch errors earlier and keep test runs cleaner, reducing the risk of defects reaching users.
Original PR description
- https://github.com/odoo/enterprise/pull/131914 Various Hoot/web tests fixes. See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#289024 Forward-Port-Of: odoo/odoo#256814
Lists created from large header text now keep their bullets properly aligned. This prevents visual overflow in the HTML editor and gives users cleaner formatting when converting styled headings into lists.
Original PR description
Problem: Creating a list on a header block with large font size content causes the list marker/bullet to overflow to the left. Cause: `ListPlugin.blockToList()` wrapped block elements into a list without invoking `this.adjustListPadding(list)`, leaving the list padding unadjusted for larger font sizes. Solution: Call `this.adjustListPadding(list)` in `blockToList` so that proper inline padding is set based on the list item content font size. Steps to reproduce: - Create a header block (e.g. Header 4). - Change the font size of the header content to be bigger. - Apply a list on the content. => Observe that the list marker overflows to the left. opw-6542903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286975
Link previews in the HTML editor now ignore metadata that contains only blank spaces. This prevents users from seeing an empty clickable preview area and ensures the link popover falls back to useful information like the URL.
Original PR description
Problem: When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: " "`), the link popover displays an empty clickable preview area.…
Problem: When a link's metadata contains whitespace-only strings for `og_title`, `og_description`, or `og_image` (e.g. `og_title: " "`), the link popover displays an empty clickable preview area. Cause: `LinkPopover` assigned raw metadata values directly. Non-empty whitespace strings evaluate to truthy values in JavaScript (`" "` is truthy), preventing fallback to the default URL or empty string. Solution: Trim the metadata values (`og_title`, `og_description`, `og_image`) when populating state so that whitespace-only values evaluate to empty strings and trigger appropriate fallbacks. Steps to reproduce: - Open HTML editor. - Add a link with URL `https://netorg4182089.sharepoint.com/:v:/s/projects/IQD72ajP3WOBT4jcAu_1qLfIAamL9lvrq4ls1Bs9XCyXJvw?e=vQ9wH3`. - Open the link popover. => Observe that the popover title falls back to the URL instead of showing an empty clickable space. opw-6564118 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#288188
Colombian electronic invoice XML files now keep the invoice note limited to the customer-facing Terms and Conditions. This prevents an internal technical control key from appearing in documents sent to DIAN, improving accuracy and avoiding unnecessary exposure of configuration details.
Original PR description
**Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the CO Company. - Disable `Test environment` and enable `DIAN Demo Mode` in the invoicing settings. - Set a `Technical…
**Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the CO Company. - Disable `Test environment` and enable `DIAN Demo Mode` in the invoicing settings. - Set a `Technical control key` on the `Customer Invoices` journal. - Create and confirm an invoice with Terms and Conditions. - Send the invoice to `DIAN`. - Open the generated XML file and observe the `cbc:Note` tag. **Observation:** The `Note` tag contains the `technical control key`. **Expected behavior:** The `Note` tag should only contain the Terms and Conditions value from the invoice. (Confirm with PO [1]) **Root Cause:** At [2] and [3], the code includes the `technical key` in the `Note` tag. [1]: https://www.odoo.com/mail/message/1164671931 [2]: https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L664 [3]: https://github.com/odoo/enterprise/blob/a5f4bde1aa33ea7b796d7ee3f9d713a6c8ab8348/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1600-L1603 opw-6513843 Forward-Port-Of: odoo/enterprise#132299 Forward-Port-Of: odoo/enterprise#131495
This update fixes inconsistencies in internal test data used across several Odoo apps, making automated checks stricter and more accurate. It helps prevent invalid sample records from hiding issues before changes reach users, with no direct change to day-to-day workflows.
Original PR description
- https://github.com/odoo/odoo/pull/256814 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#132036 Forward-Port-Of: odoo/enterprise#131914
The payroll salary configurator test was adjusted so it clicks the intended transportation option instead of occasionally selecting the wrong one. This reduces random test failures and helps keep Belgian payroll changes validated reliably.
Original PR description
Tour `hr_contract_salary_tour` fails non-deterministically on step `trigger: 'span[name="Gross"][value="2886.87"]',` There are multiple steps in the tour where a value is input and then a click is…
Tour `hr_contract_salary_tour` fails non-deterministically on step `trigger: 'span[name="Gross"][value="2886.87"]',` There are multiple steps in the tour where a value is input and then a click is made targetting `label:contains(Transportation)`[^1]. The click is made to force the update of the salary configurator's values. However, the selector is not precise enough, multiple elements match, some of which clickable and with an influence on the configurator. By looking at the screenshots from faulty runbot builds, we can see a value specified for the "Train Transportation" option, although it is not supposed to be selected at this point of the tour, which causes the value of the gross to be wrong. Runbot screenshot: <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/a520cacf-f900-4aad-ae6b-d9b7b68da716" /> Selector results (random runbot): <img width="1918" height="613" alt="image" src="https://github.com/user-attachments/assets/caae96d4-5026-48cc-aad7-d1283ab5549a" /> ----- runbot-242057 [^1]: eg. https://github.com/odoo/enterprise/blob/7ff50cf2abc02cb71f3b50d85a92f4ee52e1a66c/test_l10n_be_hr_payroll_account/static/tests/tours/hr_contract_salary_tour.js#L429
A rental planning test was corrected to use the proper local timezone before comparing dates. This prevents false test failures during early-morning hours and helps keep release validation reliable.
Original PR description
**Issue:** `test_payment_renting_product_available` test is failing when executed between 0:00 AM and 2:00 AM in Brussels timezone (UTC+2): ``` AssertionError: datetime.datetime(2026, 6, 22, 16, 0) != FakeDatetime(2026, 6, 21, 16, 0) : The planning slot should begin at the same time as the picking time. ``` In the database the datetime is stored in UTC, which is the previous day for the example above. In `test_payment_renting_product_available` test, the datetime is passed to `datetime.combine()` function that naively uses the date part, which leads to a one-day delta. The datetime should be converted to the working timezone before being passed to `datetime.combine()`. runbot-940435 Forward-Port-Of: odoo/enterprise#131944