Tuesday, September 2, 2025
8 changes · saas-18.2
Enhancements to existing features
Developers can now run selected tests directly from the Odoo shell without restarting the full server after test changes. This shortens debugging cycles and supports faster validation during development, while business logic changes still require a shell restart.
Original PR description
This commit introduces a new function `run_tests` to the Odoo shell. This function allows users to run specific tests directly from the shell, even after the test code is modified. This significantly…
This commit introduces a new function `run_tests` to the Odoo shell. This function allows users to run specific tests directly from the shell, even after the test code is modified. This significantly speeds up the debugging process by avoiding the need for a full server restart. In the odoo shell ``` >>> from odoo.tests.shell import * >>> run_tests(env, 'test_tags', modules=[module_name], reload_tests=True) ``` Note: `run_tests` automatically reloads test modules but does not reload Odoo model code. A shell restart is still required after any change to business logic. used by https://github.com/HydrionBurst/odoo-test-vscode for hot test vscode extension: [odoo-test-0.0.1.vsix.zip](https://github.com/user-attachments/files/22089685/odoo-test-0.0.1.vsix.zip) tutorial: https://github.com/HydrionBurst/odoo-test-vscode?tab=readme-ov-file#-hot-test 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#224860 Forward-Port-Of: odoo/odoo#224048
Peruvian electronic invoicing screens now show Estela as the provider name, reflecting the recent rebrand from Digiflow. This keeps labels, help text, and translations accurate for users without changing how invoicing works.
Original PR description
This PR updates the Peruvian electronic invoicing configuration to reflect the recent brand change from Digiflow to Estela (formerly Digiflow). Changes: - Updated help texts and string labels in `res_company.py` - Adjusted references in `account_edi_format.py` - Updated translations in `es.po` This change is purely textual and does not affect logic or behavior. It ensures users see the correct branding across the Peruvian EDI settings. Forward-Port-Of: odoo/enterprise#87230 Forward-Port-Of: odoo/enterprise#85934
Resolved issues and error corrections
This fix prevents Spain VeriFactu processing from failing when a company has no NIF or VAT number set. It makes invoice reporting checks more robust, reducing unexpected interruptions for affected Spanish localization users.
Original PR description
Replaced `['NIF']` with `.get('NIF')` to avoid a `KeyError` when the company does not have a NIF.
When the VAT value is not set on the company and the `_send_as_batch_check` method is executed, the system raises an error from [1].
This PR updates the code to use `.get('NIF')` instead of direct access, making it more robust.
[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/l10n_es_edi_verifactu/models/verifactu_document.py#L1165
**sentry-6829500308**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224982Online point-of-sale payments now send order dates in the expected UTC timezone. This prevents mismatches caused by local timezone conversion, helping ensure orders are recorded with the correct date and time.
Original PR description
In 2a5f1ab, we formatted the `order_date` with `toFormat(...)`, however, that transforms the date into local, while the backend expects it to be in UTC. In this commit, we set the date tz back to UTC before formatting it. opw-4942697 Forward-Port-Of: odoo/odoo#224085
This update corrects the Spanish Canary Islands tax configuration to use the field name expected in Odoo 18. It helps ensure those taxes load and behave properly during setup or updates.
Original PR description
Description of the issue/feature this PR addresses: In version 18 of Canary Islands taxes, the “price_include” field no longer exists. It is now called “price_include_override.” 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#223996
This fix makes Indonesian e-Faktur Coretax product codes easier to find when users search or select them on product templates. Users can now search by code, description, or the displayed label, reducing confusion and data entry friction.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
This update corrects a failing mobile test in the Point of Sale area. It helps keep automated quality checks reliable so future Point of Sale changes can be validated with more confidence.
Original PR description
The mobile test was failing due to an issue. opw-5059482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The PLM dashboard now counts only engineering change approvals that are actually waiting for the current user. This prevents inflated or misleading dashboard numbers when the user was only a past approver or another person still needs to approve.
Original PR description
The dashboard of PLM displays for each ECO type the number of validations pending in general, and the validations waiting for me specifically. The latter has been incorrectly computed for quite some time, as it computes how many ECOs exists where I am an approver and an approval is waiting - but there is no guarantee that the waiting approval is one of mine; it might be that I am a past approver of the ECO and that another approval (waiting for somebody else than me) exists, or that two approval are required on the same stage (one by me, one by somebody else) and I already approved. This commit switches the computation around by looking for pending approvals waiting for me, and then get the number of (non-archived) ECOs bound to them. Forward-Port-Of: odoo/enterprise#92609 Forward-Port-Of: odoo/enterprise#92348