Daily updates from Odoo
Tuesday, November 4, 2025
5 changes
2 changes
Enhancements to existing features
This change greatly speeds up the process of changing a contract template on a pending job offer. It reduces unnecessary database work so the action completes in milliseconds instead of minutes on large databases, improving responsiveness for HR teams.
Original PR description
Description ----------- - Fix performance regressions due to breaking the prefetcher via `[0]` indexing of `hr.version` and batch `write`. - Evaluate only the current employees contracts in `_get_contract_versions` for an *onchange* context, else the `hr. version` for all employees are fetched and evaluated, leading to significant overhead downstream. - Add missing index for `_remove_work_entries` Benchmark --------- On a database in 19.0, with ~10k employees, ~30k versions and ~5M work-entries, the onchange triggered when changing the contract template on a pending offer for a new lambda employee took: | | Before | After | |-------------|--------|--------| | Query Count | 107k | 349 | | Time | 2.9min | ~300ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixed an issue where checkout could get stuck loading when external tax checks failed during Brazilian sales. Instead of freezing, the system now captures the problem and shows it in the next checkout step so customers can continue or correct the issue.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
2 changes
Enhancements to existing features
This change prevents the built-in Public User from being deleted, which could previously break the login page in databases without the Website module. It helps keep public access working reliably and avoids an internal server error for users trying to sign in.
Original PR description
Steps to Reproduce:
1. Create a database without installing the Website module.
2. Navigate to archived users and delete the "Public User."
3. Attempt to log in to the database from another browser or incognito
mode.
4. An internal server error occurs because the public user does not
exist, making the login page inaccessible.
Issue:
Previously, it was possible to delete the public user, leading to an
internal server error due to its absence, which prevented public access
to the login page.
Solution:
- Implemented a restriction to prevent the deletion of the public user,
similar to portal and default users.
- Added a test case to validate this functionality and ensure the
public user cannot be deleted.
task-4423568
Forward-Port-Of: odoo/odoo#196918Resolved issues and error corrections
We fixed an issue where checkout could get stuck loading if an external tax check failed during order summary updates. Instead of freezing, the problem is now captured and surfaced so the customer can continue and see a clear message in the next checkout step.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
1 change
Enhancements to existing features
This change prevents the built-in public user from being deleted, which could previously break the login page for anonymous visitors. It also ensures that existing databases missing this user can recover correctly when the Website module is installed, avoiding an internal server error and restoring access.
Original PR description
Steps to Reproduce: 1. Create a database without installing the Website module. 2. Navigate to archived users and delete the "Public User." 3. Attempt to log in to the database from another browser or incognito mode. 4. An internal server error occurs because the public user does not exist, making the login page inaccessible. Issue: Previously, it was possible to delete the public user, leading to an internal server error due to its absence, which prevented public access to the login page. Solution: - Implemented a restriction to prevent the deletion of the public user, similar to portal and default users. - Introduced a **pre_init_hook** to verify the existence of the public user in existing databases. If missing, the user is recreated during the Website module installation. - Added a test case to validate this functionality and ensure the public user cannot be deleted. task-4423568 Forward-Port-Of: odoo/odoo#196918