Thursday, September 24, 2026
6 changes · saas-19.1
Resolved issues and error corrections
This fixes an issue where an autocomplete dropdown could reopen and remain visible after a user selected a suggestion. The change prevents delayed searches from running after the dropdown is closed, reducing failed automated checks and avoiding confusing form behavior.
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 an internal data handling issue where temporary related many-to-many fields could incorrectly reuse a database relationship. The change prevents unrelated fields from influencing each other, helping ensure records show the correct category or role information.
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#290067This fix ensures that if a user is not allowed to subscribe to one editor-related update channel, the system skips only that channel instead of failing the whole subscription request. This helps keep unrelated real-time updates working reliably for users.
Original PR description
`_build_bus_channel_list` should never raise. Otherwise, the entire request is aborted, meaning the client fails to subscribe to *all* channels, including completely unrelated channels. Instead, if a client do not have permission to subscribe to a channel, the channel should just be skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287142
The Luxembourg reports module now uses a working download link for the FAIA XSD file. This prevents failures caused by the previous link returning an empty file, helping users access the required compliance file reliably.
Original PR description
The old link points to a file with zero bytes. opw-6344914 Forward-Port-Of: odoo/enterprise#132582
When Colombian localization users update contact data in a multi-company setup, any newly created child contact now automatically receives the same company as its parent contact. This prevents contacts from being left unassigned and helps keep company records consistent.
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
Opening a previously sent signing template with no fields no longer triggers an access error. This prevents disruption for users reviewing or managing sent templates while keeping existing access rules intact.
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