Odoo Changelog — 2026-08-30

Sunday, August 30, 2026

3 changes · saas-19.3

Bug Fixes(3)

Resolved issues and error corrections

[FIX] base: _lookup_xmlids not flushing before executing SQL.

Coresaas-19.3base

This fix ensures Odoo checks the most up-to-date internal data before looking up XML identifiers. It prevents outdated settings, such as update protection flags, from being returned after changes are made.

Original PR description

Steps to Reproduce: - write on ir.model.data to modify noupdate. - _lookup_xmlids still returns the old noupdate value. Example: In [1]: imd = self.env['ir.model.data'] In [2]: xml_id =…

Steps to Reproduce:

- write on ir.model.data to modify noupdate.
- _lookup_xmlids still returns the old noupdate value.

Example:
In [1]: imd = self.env['ir.model.data']

In [2]: xml_id = self.env['ir.model.data'].search([], limit=1)

In [3]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[3]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]

In [4]: xml_id.write({'noupdate': not xml_id.noupdate})
Out[4]: True

In [5]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[5]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)]

In [6]: imd.flush_model()

In [7]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model])
Out[7]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, True, 149)]

Issue:

- _lookup_xmlids is returning values from ir.model.data executing an SQL query w/o flushing.

Fix:

- Add flushing in _lookup_xmlids.

Forward-Port-Of: odoo/odoo#262791

#xml-id#data-consistency#internal-lookup

[FIX] social_twitter: don't blind raise UserError when refreshing the feed view

PR #129771

Enterprisesaas-19.3social_twitter

Refreshing a social media feed no longer shows a generic error when the connected X/Twitter account token is invalid. Instead, the account can be disconnected as expected, reducing confusion for users managing social feeds.

Original PR description

Bug
===
If the token because invalid, then an UserError is raised instead of disconnecting the account. This is because we "blind raise" all errors we get from X, instead of filtering the error linked to the stream configuration.

Task-6499283

Forward-Port-Of: odoo/enterprise#129560
Forward-Port-Of: odoo/enterprise#129110

#twitter#social#feed#account

[FIX] l10n_latam_base: fix es_419 translations for VAT and Passport identification types

PR #273207

Coresaas-19.3l10n_latam_base

This fixes two Spanish (Latin America) labels for customer identification types in Odoo 19. Users will now see the correct local terms, showing “NIF” instead of “IVA” for VAT and “Pasaporte” instead of the English “Passport.”

Original PR description

**Description of the issue/feature this PR addresses:**

In Odoo 17 and 18, the Spanish (es_419) translation of the VAT identification type was corrected from "IVA" to "NIF" (Número de Identificación Fiscal) via the es_419.po file in l10n_latam_base. In Odoo 19, the translation mechanism for this data changed: translations are now stored as name@es_419 columns directly in l10n_latam.identification.type.csv. The correction was never applied to this new file, so the wrong value ("IVA") reappeared. Additionally, the Passport type was missing its es_419 translation entirely.

**Current behavior before PR:**

- In any Odoo 19 instance with a Latin American localization, the identification type dropdown shows "IVA" for the VAT type (es_419 locale).
- The Passport type shows the untranslated English label "Passport" in es_419 locales.

**Desired behavior after PR is merged:**

- The VAT identification type displays "NIF" in es_419 locales.
- The Passport identification type displays "Pasaporte" in es_419 locales.
- Behavior in v17 and v18 is unaffected (different translation mechanism).

**Steps to test the functionality:**

1. On an Odoo 19 instance with l10n_latam_base installed and language es_419 active, go to Contacts → Configuration → Identification Types.
2. Verify that the type with external ID l10n_latam_base.it_vat shows "NIF" (not "IVA").
3. Verify that the type with external ID l10n_latam_base.it_pass shows "Pasaporte" (not "Passport").
4. Open a contact form, set country to Argentina, and confirm the identification type dropdown reflects the corrected labels.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#272243

Steps to Reproduce: - write on ir.model.data to modify noupdate. - _lookup_xmlids still returns the old noupdate value. Example: In [1]: imd = self.env['ir.model.data'] In [2]: xml_id = self.env['ir.model.data'].search([], limit=1) In [3]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model]) Out[3]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)] In [4]: xml_id.write({'noupdate': not xml_id.noupdate}) Out[4]: True In [5]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model]) Out[5]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, False, 149)] In [6]: imd.flush_model() In [7]: imd._lookup_xmlids([xml_id.complete_name], self.env[xml_id.model]) Out[7]: [(18603, 'auth_signup', 'action_send_password_reset_instructions', 'ir.actions.server', 149, True, 149)] Issue: - _lookup_xmlids is returning values from ir.model.data executing an SQL query w/o flushing. Fix: - Add flushing in _lookup_xmlids. Forward-Port-Of: odoo/odoo#262791

Bug === If the token because invalid, then an UserError is raised instead of disconnecting the account. This is because we "blind raise" all errors we get from X, instead of filtering the error linked to the stream configuration. Task-6499283 Forward-Port-Of: odoo/enterprise#129560 Forward-Port-Of: odoo/enterprise#129110

In Odoo 19, translations for l10n.latam.identification.type were moved from .po files to inline columns in the CSV data file. The es_419 correction previously applied via es_419.po (VAT → NIF) was never ported to the new CSV mechanism, causing "IVA" to reappear. Passport was also missing its es_419 translation. **Description of the issue/feature this PR addresses:** In Odoo 17 and 18, the Spanish (es_419) translation of the VAT identification type was corrected from "IVA" to "NIF" (Número de Identificación Fiscal) via the es_419.po file in l10n_latam_base. In Odoo 19, the translation mechanism for this data changed: translations are now stored as name@es_419 columns directly in l10n_latam.identification.type.csv. The correction was never applied to this new file, so the wrong value ("IVA") reappeared. Additionally, the Passport type was missing its es_419 translation entirely. **Current behavior before PR:** - In any Odoo 19 instance with a Latin American localization, the identification type dropdown shows "IVA" for the VAT type (es_419 locale). - The Passport type shows the untranslated English label "Passport" in es_419 locales. **Desired behavior after PR is merged:** - The VAT identification type displays "NIF" in es_419 locales. - The Passport identification type displays "Pasaporte" in es_419 locales. - Behavior in v17 and v18 is unaffected (different translation mechanism). **Steps to test the functionality:** 1. On an Odoo 19 instance with l10n_latam_base installed and language es_419 active, go to Contacts → Configuration → Identification Types. 2. Verify that the type with external ID l10n_latam_base.it_vat shows "NIF" (not "IVA"). 3. Verify that the type with external ID l10n_latam_base.it_pass shows "Pasaporte" (not "Passport"). 4. Open a contact form, set country to Argentina, and confirm the identification type dropdown reflects the corrected labels. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272243