Tuesday, November 4, 2025
6 changes · 17.0
Enhancements to existing features
This update makes an error message more explicit when the system rejects files from an uninstalled module. It should help support teams and users understand the cause faster and troubleshoot without digging into the code.
Original PR description
While working on a support ticket, I was faced with this exception handling: https://github.com/odoo/odoo/blob/49061347c181b1a451435bc363bb9508db8b6fab/odoo/addons/base/models/ir_asset.py#L344-L346 It might be nitpicky, but given the if condition, the exception error text could be more explicit about the fact that it's raised because the files in question being from an uninstalled addon/module. This might fast track troubleshooting without having to dive into the source code to understand why the error is being raised. There is always the possibility that I might be missing some context or other scenarios where this error could be raised. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures the system returns the correct copied email template instead of reusing the wrong one. It prevents unexpected template content from showing up when users duplicate mail templates.
Original PR description
Fix reused variable name
When a deferred start date is entered without an end date, the system now automatically uses the same date for both values. This prevents invalid accounting periods and makes the setup flow smoother for users in stable versions.
Original PR description
Previously, specifying a Deferred Start Date without an End Date would result in an invalid period. This commit updates the logic to default the End Date to the value of the Start Date if the End Date is not provided. This streamlines the flow in stable versions until a more comprehensive solution is implemented in master. Task-5207293
This update fixes an automated test so it can run correctly even when demo data is not installed. It ensures the required accounting setup is available, preventing the test from failing when creating a purchase invoice.
Original PR description
The test `test_dropship_return_backorders_bill_on_order` failed when running without demo data because no chart of accounts was installed, so no Purchase journal existed. As a result, `purchase_order.action_create_invoice()` raised: UserError: No journal could be found in company ... for any of those types: purchase This change inherits from `AccountTestInvoicingCommon` to have the necessary charts. [runbot-231285](https://runbot.odoo.com/odoo/error/231285) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves the export dialog’s search so users can find fields by their visible names, even when those names include parent paths like “Order Lines/Product.” It prevents missed results caused by a mismatch in the search logic, while still keeping technical field IDs usable in debug mode.
Original PR description
The export dialog reverses field.string to prioritize field names over parent paths
in fuzzy search scoring. However, the search pattern was not reversed, causing
mismatches when searching with display names like "Order Lines/Product".
Before: pattern "Order Lines/Product" searched in reversed string "Product/Order Lines"
→ character order mismatch → no results
After: both pattern and string are reversed → proper matching
This fix ensures searching by display names (e.g., "Order Lines/Product") works
as expected, while technical IDs (e.g., "order_line/product_id") continue to work
in debug mode.
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-prThis update prevents Shiprocket from failing when taxes do not include India GST tags. It also makes the related test more reliable by explicitly using a 15% tax rate, so results are consistent across different company settings.
Original PR description
Some other test adds a fiscal position with tax mapping. This creates 2 problems
1. The new taxes have a tag, which means we evaluate the right hand of
https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239
However, since l10n_in is not installed,
`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`
does not return anything (False is not a fallback)
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588
So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558
2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true
Solution
-----
1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test
-----
runbot-232692