Monday, July 21, 2025
12 changes · saas-18.4
Resolved issues and error corrections
Discuss now continues to load inbox and history messages even when a notification refers to a record that has since been deleted. This prevents users from seeing a generic fetch error and keeps message access reliable after related records are removed.
Original PR description
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive…
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive notification in Odoo - Install `mail_group` - Wait a few seconds to receive following user_notification from mail group: ``` on My Company News Hello, You have messages to moderate, please go for the proceedings. ``` - Go to related record then delete it - Go back to inbox or history => One of them show `An error occurred while fetching messages.` This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications. `mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with: ``` MissingError: Record does not exist or has been deleted ``` This commit fixes the issue by doing its best to show message even when the related record has been deleted. opw-4546920 Before  After  Forward-Port-Of: odoo/odoo#219795 Forward-Port-Of: odoo/odoo#219758
This fix corrects how Mexican DIOT report tax columns are tagged and calculated so they show the intended tax amounts instead of mixing in base amounts or multiple tax types. This improves the accuracy of VAT-related reporting for Mexican localization users.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. Current behavior before PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. Desired behavior after PR is merged: Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly. Likewise, the way of computing the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% has been simplified. Now it no longer adds up different types of taxes, but only one type. opw-4920577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218707 Forward-Port-Of: odoo/odoo#217441
Users can now open their inbox and message history even when a notification refers to a record that has since been deleted. This prevents message loading errors in Discuss and helps ensure important notifications remain accessible.
Original PR description
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive…
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive notification in Odoo - Install `mail_group` - Wait a few seconds to receive following user_notification from mail group: ``` on My Company News Hello, You have messages to moderate, please go for the proceedings. ``` - Go to related record then delete it - Go back to inbox or history => One of them show `An error occurred while fetching messages.` This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications. `mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with: ``` MissingError: Record does not exist or has been deleted ``` This commit fixes the issue by doing its best to show message even when the related record has been deleted. opw-4546920
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#218810Indian e-invoicing setup now shows the detailed error message and code returned when authentication fails. This helps users and support teams understand the reason for failed authorization faster and resolve configuration or service issues with less back-and-forth.
Original PR description
Previously, the `UserError` raised on authentication failure did not include the error message returned by the IAP server.
In this commit:
---
- Added logic to extract and include detailed error messages with code from the IAP response in the `UserError` during authentication for e-invoicing.
Related Tickets:
---
opw-4908388
opw-4942744
opw-4946339
opw-4946193
opw-4933833
Forward-Port-Of: odoo/odoo#219443
Forward-Port-Of: odoo/odoo#219277Vietnamese Viettel e-invoice data now aligns with updated local address rules by no longer sending a buyer district. The buyer city can now use either the city or state information, reducing failed or incorrect invoice submissions when customer address details are incomplete.
Original PR description
* Problem: Since what has been described in https://github.com/odoo/odoo/pull/214134 and https://thuvienphapluat.vn/chinh-sach-phap-luat-moi/vn/ho-tro-phap-luat/chinh-sach-moi/82581/tu-ngay-01-7-2025-ca-nuoc-se-khong-con-quan-huyen Vietnam no longer have district and city in city no more (Before in Vietnam we will have Thu Duc City belong to Ho Chi Minh State or Thuy Nguyen City belong to Hai Phong), Therefore we need to update Sinvoice data for this to. * This commit remove BuyerDistrict parameter , beside using state in the district is totally wrong and for 'buyerCityName' accept city or state field because odoo user might leave the city empty and just input state 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#218984
This 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
This fix updates the Mexican DIOT report so it uses the latest column definitions from related accounting changes. It helps ensure DIOT tax report values are calculated and shown in the correct places, reducing confusion and reporting errors.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were…
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. This issue was addressed in PR: https://github.com/odoo/odoo/pull/217441, but a small adjustment still needs to be made in the l10n_mx_reports module. Current behavior before PR: The l10n_mx_diot_get_values function uses references to the old account.report.expression that were removed in the pr mentioned above. Desired behavior after PR is merged: The l10n_mx_diot_get_values function uses the new references to account.report.expression that were introduced in the pr of the community repo. opw-[4920577](https://www.odoo.com/odoo/my-tasks/4920577) "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" Forward-Port-Of: odoo/enterprise#90119 Forward-Port-Of: odoo/enterprise#89481
The rental schedule's "To Do Today" filter now correctly accounts for each user's local timezone before checking today's rentals. This prevents rental orders from appearing too early or being missed for users outside UTC.
Original PR description
__Issue:__ The "To Do Today" filter used the user's local date to build a datetime range but treated it as if it were already in UTC. This caused incorrect filtering in non-UTC timezones __Fix:__ - Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-4886069 Forward-Port-Of: odoo/enterprise#90358 Forward-Port-Of: odoo/enterprise#89718
Signed documents now correctly show the option chosen in selection fields after validation. This ensures completed agreements accurately display all signer-provided information when reopened or reviewed.
Original PR description
Steps to reproduce: 1. Install the sign module 2. Sign > template menu 3. Create a template with a signature and a selection field. 4. Sign the document and select a value in the selection field. 5. Validate the document 6. Reopen the signed document Issue: - The selected value was not shown after signing. Cause: - The display logic for the selected value was missing. - Logic was removed by this commit https://github.com/odoo/enterprise/commit/0cd6b4d08af0c9be5c74f6aee30d8fe890fc7c1 Solution: - Added code to render the selected value in signed documents. opw-4908385 Forward-Port-Of: odoo/enterprise#89380
Advance payments now correctly generate invoices for the next subscription period when an order includes both recurring and one-time products. This prevents missed billing after the first period and helps ensure subscription revenue is invoiced on schedule.
Original PR description
Steps to Reproduce: 1. create a subscription with a recurring & non-recurring product(select monthly cleaning quatation) 2. Pay for the first period. 3. Now, try to pay the advance payment for the second period. The invoice is not generated for the second duration Issue: - The invoice is not generated for the second period. Cause: - The _get_partial_payment_subscription_transaction method incorrectly compares the sum of authorized, uninvoiced transactions with the total order amount. Solution: - Update the _get_partial_payment_subscription_transaction method to compare the sum of authorized, uninvoiced transaction amounts with the next billing period’s total instead of the full order total task-4780971 Forward-Port-Of: odoo/enterprise#90453 Forward-Port-Of: odoo/enterprise#85114
Intrastat reports no longer preselect journal filters, helping ensure credit notes are included automatically. This reduces the risk of incomplete arrivals reporting and gives customers more reliable Intrastat declarations.
Original PR description
- Before this PR: Customers often miss credit notes in Intrastat arrivals due to filtering on purchase journals only, which results in incomplete reports. - After this PR: Journal filters are now unticked by default in both root and variant Intrastat reports. - Task ID: 4936349 Forward-Port-Of: odoo/enterprise#90415 Forward-Port-Of: odoo/enterprise#90131