Monday, July 21, 2025
2 changes · saas-18.4
Resolved issues and error corrections
The Argentina localization now handles invalid partner identification numbers safely instead of crashing when non-numeric values are entered. This helps users continue creating or editing Argentina partners while the system flags invalid VAT or ID data appropriately.
Original PR description
The system crashes when trying to `sanitize invalid VAT` inputs for `Argentina partners` due to the assumption that the identification number can always be safely cast to int(). **Steps to…
The system crashes when trying to `sanitize invalid VAT` inputs for `Argentina
partners` due to the assumption that the identification number can always be
safely cast to int().
**Steps to reproduce:-**
- Initialize a database with `demo data`.
- Install the `l10n_ar` module and switch to the `AR Company`.
- Create a partner with:
- Country: `Argentina`
- Identification Method: `DNI`
- Number: `test`
- Observe the error.
**Error:-**
`ValueError: invalid literal for int() with base 10: ''`
**Root cause:-**
- The method `_run_check_identification` is introduced after this [commit](https://github.com/odoo/odoo/pull/179078)
- in this method, when [1] is executed, then `get_id_number_sanitize` method
is called.
- At [2], the error occurs because `_get_id_number_sanitize()` assumes the VAT
is numeric after removing `non-digit characters`. If the VAT input is non-
numeric (e.g., 'test'), it becomes an `empty string ''`, and converting that to
int('') raises an error.
**Solution:-**
- Added a VAT validity check using `_check_vat_number()` at the start of
`_get_id_number_sanitize()`. If the VAT is invalid, we return 0
early to prevent `int()` conversion errors.
[1]: https://github.com/odoo/odoo/blob/2c019833bbc771866fb9a1c0021d87b8b07ed411/addons/l10n_ar/models/res_partner.py#L63
[2]: https://github.com/odoo/odoo/blob/2c019833bbc771866fb9a1c0021d87b8b07ed411/addons/l10n_ar/models/res_partner.py#L134-L135
**sentry-6743438515**
Forward-Port-Of: odoo/odoo#218810This fixes an internal test setup issue that caused automated checks to fail when employee-related data was expected but not available. It helps keep the Discuss enterprise test suite reliable, reducing false failures in the release pipeline.
Original PR description
Before this commit, recently added unit test "can handle command and disable mentions in AI composer" crashed on runbot with the following error message: ``` cannot find a definition for model…
Before this commit, recently added unit test "can handle command and disable mentions in AI composer" crashed on runbot with the following error message: ``` cannot find a definition for model "hr.employee": could not get model from server environment (did you forget to use `defineModels()?`) ``` Somehow the mock models in this test suite is aware of model "hr.employee". While this model exists with this module installed, the hoot suite in `test_discuss_full_enterprise` only imports mail models which hasn't `hr.employee`, thus we'd expect the suite to not be aware of this model and shouldn't attempt to load it. While we don't know why the hr.employee model definition is obtained on runbot on this test suite, functionally it makes sense to have this model installed. At the same time, we'd expect that the JS model definition are optional and just there in case we want to "cheat" model definition from the one fetched. This commit attempts to fix the issue by defining hr models rather than mail models in this test suite. Hr models have mail models in addition to hr models like hr.employee, thus we expect to fix the crash. Fixes runbot-error-230073 Forward-Port-Of: odoo/enterprise#90604