Thursday, September 24, 2026
9 changes · saas-19.3
Enhancements to existing features
This improves internal Argentina localization report tests by creating sample invoices more efficiently. It reduces test setup time and database work while keeping report results unchanged, helping maintain faster and more reliable development checks.
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#290123 Forward-Port-Of: odoo/odoo#290111
This change speeds up preparation of Argentine localization report tests by creating sample vendor bills more directly. It reduces automated test time while keeping report results unchanged, helping future updates be validated faster.
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#132841 Forward-Port-Of: odoo/enterprise#132697
Resolved issues and error corrections
Fixes an issue where a selection dropdown could reopen and remain visible after a user picked an item. This improves reliability for users working with selection fields and prevents related automated checks from timing out.
Original PR description
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to…
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to close then times out:
FAILED: [8/36] Tour mail_template_dynamic_placeholder_tour
Step Wait for the drop down to disappear
(trigger: div[name="model_id"] .o-autocomplete:not(:has(.ui-autocomplete)))
TIMEOUT step failed to complete within 10000 ms.
This happens because the search filling the dropdown runs 250ms after the last keystroke, so a suggestion of the previous search can be picked while the next search is still scheduled. Picking a suggestion only closes the dropdown. The scheduled search then runs, opens the dropdown on the selected value, and nothing closes it after that.
This commit fixes the issue by discarding the scheduled search when the dropdown closes.
https://runbot.odoo.com/odoo/error/233574
https://runbot.odoo.com/odoo/error/237744
https://runbot.odoo.com/odoo/error/944454
https://runbot.odoo.com/odoo/error/945517
https://runbot.odoo.com/odoo/error/947141
Forward-Port-Of: odoo/odoo#290317
Forward-Port-Of: odoo/odoo#287888This fixes a notification mismatch so tracking-related mail updates are recognized as already handled by browser push notifications. Users should see fewer duplicate alerts when they are away from the Odoo window, making notifications less noisy.
Original PR description
Since #290266 there is a whitelist of message types matching what the server sends via web push, used by the JS `out-of-focus` notifier to skip its own alert and avoid duplicates. `tracking` was added as a server-side push message type in `saas-19.3` (#235719) and should be considered in the JS whitelist as well.
This fixes an internal data-model issue where certain related, non-saved many-to-many fields could incorrectly keep a database relationship. The change helps prevent values from being mixed between similar fields, improving data consistency without changing normal user workflows.
Original PR description
When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have…
When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have side-effects like finding sibling fields in 20.0: in the code below, reading categories would fill roles.
```py
model_id = self.env["ir.model"]._get("test_new_api.foo")
fields = [{
"name": "x_partner_id",
"ttype": "many2one",
"relation": "res.partner",
}, {
"name": "x_role_ids",
"ttype": "many2many",
"relation": "res.partner.category",
}, {
"name": "x_partner_category_ids",
"ttype": "many2many",
"relation": "res.partner.category",
"related": "x_partner_id.category_id",
"store": False,
"readonly": True
}]
for f in fields:
f["model_id"] = model_id.id
self.env["ir.model.fields"].create(fields)
env['test_new_api.foo']._fields['x_partner_category_ids'].relation # should be None
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#290286
Forward-Port-Of: odoo/odoo#290067Message previews in Mail now display the actual text for certain in-app links instead of showing placeholder hash symbols. This makes notifications such as pinned messages and join messages clearer and avoids confusing preview text.
Original PR description
Before this commit, JS-handled links (e.g. pinned messages notification, joined notification) would be formatted as "#" in `htmlToHtmlInline()` (introduced in [1]). This causes message preview for pinned message notification to show as "# #". This commit fixes the issue by specifically handling JS-handled links (recognized by odoo-specific data attributes) and rendering their tet content. [1]: https://github.com/odoo/odoo/pull/238080 task-6571060 Forward-Port-Of: odoo/odoo#290292
Opening a signing template after it has been sent no longer triggers an access error when the template has no fields. This prevents users from being blocked when viewing previously sent templates in the Sign app.
Original PR description
Version: 19.0 Steps to reproduce: - Create a sign template with no sign fields - Send a sign request using that template - Open that template from Templates Issue: After a sign request is sent, record rules make the template read only for sign items (create/write only when there are no sign requests). On open, if the template has no signers, the UI auto creates a dummy signer. For an empty sent template, that create is denied by those rules and raises an Access Error. Fix: Guard the auto create signer flow with a sign requests check so that a sent template does not try to create a new signer on open. Task: 6591146 Forward-Port-Of: odoo/enterprise#132516
When Colombian localization users update contact data in a multi-company setup, any new related contact now automatically uses the same company as the original contact. This prevents missing company assignments and keeps customer records consistent across companies.
Original PR description
Problem: In l10n_co, when updating a contact's data using the "Update data" feature in a multi-company setup, the company of the newly created child contact isn't set. Solution: Set the child contact's company to match the parent contact's company when creating the record, ensuring both contacts belong to the same company. Steps to reproduce (runbot v18): 1. Install l10n_co 2. Set up two companies (Company A and Company B). 3. Create a contact with an email and NIT, and set its company to Company B. 4. Click the "Update data" button. 5. Open the newly created child contact and check its company. The company of the newly created child contact is not set. opw-6528295 Forward-Port-Of: odoo/enterprise#131049
The Luxembourg reports module now uses a working download link for the FAIA XSD file. This prevents failed or empty downloads when users need the required reporting schema file.
Original PR description
The old link points to a file with zero bytes. opw-6344914 Forward-Port-Of: odoo/enterprise#132582