Sunday, August 30, 2026
5 changes · saas-19.4
Enhancements to existing features
Pay Later receivable entries in Point of Sale are now reconciled in one grouped operation instead of repeated partner-by-partner processing. This keeps the accounting result unchanged while reducing processing overhead, especially for sessions with many customers using Pay Later.
Original PR description
The pay later receivable lines are reconciled with one `reconcile()` call per partner, and each call filters the whole set of lines again. Reconcile them in a single `_reconcile_plan` call grouped by partner instead: the result is the same, but the recompute cascade of the ORM runs once instead of once per partner. opw-6458271 Related: https://github.com/odoo/odoo/pull/281495 Forward-Port-Of: odoo/enterprise#129637 Forward-Port-Of: odoo/enterprise#127415
Resolved issues and error corrections
This fixes an internal lookup so it uses the latest saved changes instead of stale values. It helps keep system metadata behavior consistent after updates, reducing the risk of incorrect configuration decisions.
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#262791This fix prevents upgrades from trying to change an existing Indian cash rounding setting when it is already used by an open Point of Sale session. This avoids upgrade failures for affected businesses and helps ensure a smoother move between Odoo versions.
Original PR description
An issue occurs during the database upgrade From version 19.2 to 19.3. During the upgrade, the system attempts to update the `name` and `rounding` configuration of the Cash Rounding account. If the…
An issue occurs during the database upgrade
From version 19.2 to 19.3.
During the upgrade, the system attempts to update
the `name` and `rounding` configuration of the Cash Rounding account.
If the Cash Rounding record is linked to
an open POS session, the update fails with
the following constraint error:
```
You are not allowed to change the rounding configuration while a POS session using it is already opened.
```
To avoid this traceback during the upgrade,
set the record's noupdate attribute to True so that it is not modified.
```
File "/home/odoo/src/odoo/saas-19.3/odoo/tools/convert.py", line 485, in _tag_record
record = model._load_records([data], self.mode == 'update')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4566, in _load_records
data['record']._load_records_write(data['values'])
File "/tmp/tmpxr_9kp1h/migrations/base/0.0.0/pre-models-load_write.py", line 46, in _load_records_write
return super()._load_records_write(values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 4487, in _load_records_write
self.write(values)
File "/home/odoo/src/enterprise/saas-19.3/ai_fields/models/models.py", line 57, in write
res = super().write(vals)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.3/ai/models/models.py", line 339, in write
return super().write(vals)
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 3860, in write
real_recs._validate_fields(vals, inverse_fields)
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 1295, in _validate_fields
check(records)
File "/home/odoo/src/odoo/saas-19.3/addons/point_of_sale/models/pos_order.py", line 1575, in _check_session_state
raise ValidationError(
odoo.exceptions.ValidationError: You are not allowed to change the rounding configuration while a pos session using it is already opened.
```
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
Forward-Port-Of: odoo/odoo#281174This fixes Spanish (Latin America) labels for identification types in Odoo 19. Users will now see the correct local terms, with VAT shown as “NIF” and Passport shown as “Pasaporte,” reducing confusion when managing contacts.
Original PR description
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…
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#272243This fix makes forum internal tests reliable when demo forum data is present. It prevents unrelated demo records from causing false test failures, improving confidence in automated checks without changing user-facing forum behavior.
Original PR description
`TestForumInternals` assumed that only the base forum and the forum created by the test setup existed in the database. This is not true when tests are run with demo data. In particular,…
`TestForumInternals` assumed that only the base forum and the forum created by the test setup existed in the database. This is not true when tests are run with demo data. In particular, `website_slides_forum` creates additional demo forums, causing `test_assert_initial_values` and the forum count assertions to fail even though the forum behavior itself is correct. This commit avoids relying on the global number of existing forums and instead scope the initial-value assertions to the forums owned by the test itself. For forum count tests, we use the count observed at the beginning of the test as a baseline and assert the expected deltas after creating or updating forums. This keeps the test focused on the behavior being tested while allowing unrelated forums to already exist. This also avoids modifying, archiving, or explicitly filtering demo records, and does not introduce a dependency on modules such as `website_slides_forum`. The tests therefore behave identically on databases both with and without demo data. [error-241100 ](https://runbot.odoo.com/odoo/error/241100) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282929