Daily updates from Odoo
Navigate
Branch
Monday, July 21, 2025
10 changes
8 changes
Enhancements to existing features
Tax return entries on the accounting dashboard, such as monthly VAT returns, can now be clicked directly. This opens the relevant Tax Return view with clearer filtering and monthly grouping, helping users review returns faster and with less navigation.
Original PR description
This commit improves the accounting dashboard by making the tax return entries (e.g., VAT Apr, VAT May) clickable. Clicking on a return now opens Tax Return view filter by return type and the grouped by month for better clarity and consistency. > Task-4912633 Forward-Port-Of: odoo/enterprise#89533
Resolved issues and error corrections
Intrastat goods and services reports no longer apply journal filters by default, helping ensure credit notes are included in arrivals reporting. This reduces the risk of incomplete Intrastat declarations for companies using standard or localized report variants.
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
Completed signing documents now correctly display the option chosen in selection fields. This ensures users and recipients can see the full signed record after validation, avoiding confusion or missing information.
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
The rental schedule’s “To Do Today” filter now correctly accounts for each user’s local timezone. This prevents rental orders from appearing on the wrong day for users outside UTC, improving day-to-day scheduling accuracy.
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
Subscriptions with recurring products now require a recurring plan before customers can preview or pay. This prevents confusing payment failures by warning users earlier and blocking invalid payment links.
Original PR description
Reproduce: 1. Create a Subscription with a recurring product but without selecting a recurring plan 2. Click on "Preview" 3. Proceed to confirm and attempt to make a payment. Issue: - The subscription is treated as regular SO, and the make payment then raise Error - When generate a payment link or proceed to payment then raise Error Solution: - Add validation in the `action_preview_sale_order` method to raise `UserError` - Add validation during payment link generation: disable the payment button and display a warning message in the wizard to prevent proceeding task-4925735 Forward-Port-Of: odoo/enterprise#89942
Fixed an issue where subscriptions containing both recurring and one-time products could fail to generate an invoice for a future billing period after an advance payment. This ensures customers are billed correctly for the next period and reduces manual follow-up for subscription payments.
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#90565 Forward-Port-Of: odoo/enterprise#85114
Updates the Mexican DIOT report so it uses the latest report column references introduced by related accounting changes. This keeps DIOT tax reporting aligned with the corrected column logic and helps avoid incorrect or broken report values.
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
This change updates the enterprise Discuss test setup so it includes HR-related data models needed during automated testing. It prevents a runbot crash in the AI composer test, helping keep validation pipelines reliable without changing end-user behavior.
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
2 changes
Resolved issues and error corrections
A flaky automated test in the Mail/Discuss area was updated so it waits for conversations to be fully loaded before checking new message behavior. This reduces false test failures and helps keep delivery pipelines reliable without changing customer-facing functionality.
Original PR description
Before this commit, new test "Show conversations with new message in chat hub (outside of discuss app)" would non-deterministically crash with following error: ``` Failed to find 0 of ".o-mail-ChatBubble[name='Dumbledore']" (Timeout of 3 seconds). Found 1 instead. ``` This happens because the test `start()` and immediately simulate a new message from another user to show a chat bubble with badge "1". The badge is shown when this is a new message from init messaging, which doesn't necessarily mean `await start()` has messaging fully initialized. When discuss is not fully initialized, the new message post would be considered as not a new message and thus wouldn't open a chat bubble with badge. This commit fixes the issue by using a similar pattern as many other tests to ensure discuss is fully loaded initially: have it open a conversation with at least 1 message and assert the message is visible on the UI. Fixes https://runbot.odoo.com/runbot/build/85195954
* 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 pa
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