Monday, October 13, 2025
22 changes · saas-18.3
Enhancements to existing features
This update improves the internal Hoot testing tools used by Odoo developers, making automated tests more accurate and easier to maintain. It focuses on test-only behavior, reducing risk to business features while helping teams catch issues more reliably.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/96647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230556
Resolved issues and error corrections
The Indian localization test setup was adjusted so standalone tests no longer depend on the US accounting module when demo data is unavailable. This reduces test failures and improves reliability for maintaining the Indian localization without affecting end users.
Original PR description
Standalone `l10n_in` tests were failing when running without demo data because outside-India companies (e.g., US) were defaulting to their country-based chart of accounts. This required the `l10n_us_account` module, causing errors when the module was not installed. <img width="518" height="28" alt="image" src="https://github.com/user-attachments/assets/748663a0-f329-459c-b0e8-0c3de7019258" /> This commit adapts the test cases to run without l10n_us_account dependency. task- 5116352 Forward-Port-Of: odoo/odoo#230041
The commission achievement report now uses the latest end date from relevant commission plans as the default in all cases. This prevents reports from accidentally covering too short a period, helping sales teams and managers see complete commission results.
Original PR description
When there is active_plan_ids in the context the date_to are the max of plans' date_to when not it's the min, this is wrong it should be the maw as well
This fix improves commission reporting reliability by ensuring related adjustment logs generate distinct achievement records. It prevents rare duplicate identifier collisions that could cause commission achievements to be merged or reported incorrectly.
Original PR description
This commit 5b6fdda126e4cfa5ebf92f7b96d1805f6c4b992b introduce an entropy date to avoid having two separate achievment.report record with the same ID. Entropy date for log where based on the write_date, this commit 03d1ee3495a4936fbff0d21743bb784c85b50b12 add the sign of the amount. Unfortunatly this is not enough, the adjustment after the transfer can be positive as well and thus two achievment ends-up with the same ID anyway. This commit use the id of the log to add more entropy to the entropy_date, since log are created in the same transaction, they are likely to have id just seperate by one or only few number, id % 10 seems enough, therefore two log on the same order, with the same create_date will have different entropy date and end up with a different id.
This update adds safeguards so Danish Nemhandel connections are neutralized in non-production copies. Existing proxy clients are switched to demo mode, and new registrations use the test server to avoid unintended live sending or registration.
Original PR description
To avoid sending/registering on production, add a neutralize script. The existing proxy client are put in demo mode. The new connections will be registered on the test server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229934
This fix prevents the mail system from crashing when it receives an incorrectly formatted email address without an '@' symbol. It makes email alias handling more robust, reducing the chance of interruptions caused by malformed incoming emails.
Original PR description
Just be sure emails contain at least an '@', otherwise partition may crash. Forward-Port-Of: odoo/odoo#231171
Equipment pages now open reliably even when a completed maintenance request has had its repair dates cleared through customization or manual changes. The system treats missing dates safely instead of showing an error, reducing disruption for users viewing equipment records.
Original PR description
Using standard Odoo, `maintenance.request.close_date` should never be `False` when its `stage_id == 'done'`, but customizations/manual overrides allow users to force it to be `False` and block them…
Using standard Odoo, `maintenance.request.close_date` should never be `False` when its `stage_id == 'done'`, but customizations/manual overrides allow users to force it to be `False` and block them from opening equipment views that displayed fields that depended on it. Steps to reproduce: - Create new maintenance request for an equipment - Put maintenance request into a `maintenance.stage` where `done=True` (e.g. "Repaired") - Force `close_date` to not be `readonly` in form view + set it to `False` - Try to open the assigned equipment's form view Expected result: Form view opens without issue Actual result: `unsupported operand type(s) for -: 'bool' and 'datetime.date'` Issue was due to `mttr` calculation in `_compute_maintenance_request` not expecting `close_date` to be `False`. Since we want the request to still be considered for the rest of the compute, we count its "Time to Repair" as 0 in this case since we cannot use infinity in this case. Additionally, we also gracefully fail in the same way in case `request_date` is also forced to be `False` since it is not a mandatory field and can cause the same issue. 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#230942 Forward-Port-Of: odoo/odoo#230821
Employee contracts in multi-company setups now only show insurance records belonging to the relevant company. This prevents users from accidentally selecting another company's insurance, improving payroll data accuracy for Swiss ELM transmissions.
Original PR description
Currently, in a multi-company setup, you are able to select insurances from other companies on the employee contract task-5157106 Forward-Port-Of: odoo/enterprise#96821
This fixes a sales module issue where automated checks could fail when a custom field was placed before the product field on sales order lines. The change makes the product configurator test steps more robust, helping ensure custom sales order layouts do not cause false test failures.
Original PR description
To reproduce: 1. Manually modify the SO view `view_order_form` notebook SO lines list view to make visible any column before `product_id` For example:…
To reproduce:
1. Manually modify the SO view `view_order_form` notebook SO lines list view to make visible any column before `product_id` For example:
https://github.com/odoo/odoo/blob/18.0/addons/sale/views/sale_order_views.xml#L521 making the field `display_type` visible
2. Run the tests of `sale` module
=> `sale` module tests will fail on test `test_sale_combo_configurator_preconfigure_unconfigurable_ptals`
```
FAILED: [18/22] Tour sale_combo_configurator_preconfigure_unconfigurable_ptals → Step Verify that configurable ptals are now configured (trigger:
.sale-combo-configurator-dialog
.combo-item-grid
.product-card:has(.card-title:contains("Test product"))
:contains("Attribute B: B")).
Element (
.sale-combo-configurator-dialog
.combo-item-grid
.product-card:has(.card-title:contains("Test product"))
:contains("Attribute B: B")) has not been found.
TIMEOUT step failed to complete within 10000 ms.
```
see runbot build fail at:
https://runbot.odoo.com/runbot/build/89552334
The issue happen as - for some dark magic JS/XML reason - adding the field before product_id make fail the step to click the checkbox using the span.
Fix was suggested by PIPU to solve/workaround the issue
In practice, this issue was discovered accidentally with a customisation which was willing to add a custom field at the start of the list
opw-5068699
Forward-Port-Of: odoo/odoo#228029This fixes how fleet vehicles are marked when a driver is assigned a new or future vehicle. Other vehicles for the same driver are now marked as planned for change, while the vehicle being assigned is not incorrectly flagged, reducing confusion in fleet management.
Original PR description
WHen a new vehicle is created for someone in a non waiting column, we are settign his other cars in plan_to_change. When we set a future driver on a car, we set the others as plan to change, but not the one on which we are setting the future_driver --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents byte-based error details from being incorrectly displayed as a list of numbers in translated messages. Users will now see clearer, more readable error messages when certain system connections, such as email server tests, fail.
Original PR description
Improvements introduced by https://github.com/odoo/odoo/pull/197702 streamlined the auto formating of iterables to lists when passed as an argument to translatable strings in Odoo. While doing so,…
Improvements introduced by https://github.com/odoo/odoo/pull/197702 streamlined the auto formating of iterables to lists when passed as an argument to translatable strings in Odoo.
While doing so, strings were ignored (to prevent formating them as a list of the individual characters), but they failed to account for the fact that **byte strings** might also be passed as arguments in certain parts of the code.
An example can be found here:
https://github.com/odoo/odoo/blob/f037c39ad4d33384f81a418cb63fcdd6a5085d56/odoo/addons/base/models/ir_mail_server.py#L265-L278
`repl` in this context will be a byte string object returned by the SMTP connection.
## BUG:
Before the fix, if you would pass a byte string as an argument to a translatable string using keyword templating, the output would be the raw representation of the bytes as a list instead of the human readable content.
For example if we use in a french localisation:
`raise UserError(_('The server refused the test connection with error %(repl)s', repl=b'TEST byte string'))`
Before the fix we could get:
`Le serveur a refusé la connexion de test avec l'erreur 84, 69, 83, 84, 32, 98, 121, 116, 101, 32, 115, 116, 114, 105, 110 et 103`
And after the fix:
`Le serveur a refusé la connexion de test avec l'erreur b'TEST byte string'`
## Proposed fix:
In the same way that we ignore `str` arguments before auto applying the `format_list` method, we will also ignore them if the type is `bytes`
OPW-5107313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where certain dropdown menus could appear shifted when their contents were wider than the button opening them. This improves visual consistency and prevents confusion when users interact with menus in the web interface.
Original PR description
This commit fixes the position of the SelectMenu, that was not aligned properly when the content of the menu is larger than the toggler width before applying any maxWidth. Because the 'fit' variant sets the same width to the popper by default, and the code was applying this width after the computation of the position of the popper, the menu was displaced. Now, the width is applied before positioning the menu, which then computes accordingly. A test has been added as well. task-4674144 Forward-Port-Of: odoo/odoo#224568
The event form now correctly shows the community menu button when the Track Quiz feature is installed. This restores expected access for users managing event quiz-related community options, especially when the separate event meeting feature is not installed.
Original PR description
In the event form the "community" button is supposed to be shown when "track quiz" is installed. However when this was done in [1] there a mistake was made and only the label was removed, as well as the wrong field added after it. That field was removed in [2] but it was again not noticed that only the label was made visible. It may not appear easily because installing website_event_meet also unhides both the label and the field. Hence you only ge this issue when installing track quiz without it. However in 18.3 [3] removed website_event_meet which means the issue is not corrected anymore. task-5159806 [1]: https://github.com/odoo/odoo/commit/147cf5f328f5a55882a62a4279d1d92511628320 [2]: https://github.com/odoo/odoo/commit/c0f0f9f47573b74ca6b1fcdc3383e43f28f7a2e1 [3]: https://github.com/odoo/odoo/commit/9cab4f8f77f71e405971c184544765e8f252a012 Forward-Port-Of: odoo/odoo#231020
United Kingdom supplier or partner records are now assigned the correct DIOT country code instead of being grouped under “Other country.” This improves the accuracy of Mexican tax reporting and reduces manual review or correction needs.
Original PR description
The DIOT country adaptation map lacked the ISO 3-letter code for the UK, causing records with country 'GB' to be reported as 'ZZZ' ("Other country").
Added mapping 'GB' → 'GBR' to ensure correct DIOT country code generation.
Forward-Port-Of: odoo/enterprise#96771This fix makes follow-up report tests use a consistent date, preventing failures when tests run across midnight. It improves confidence in automated validation without changing business functionality for users.
Original PR description
Tests https://runbot.odoo.com/odoo/runbot.build.error/159772 where failing when setUpClass run before midnight and the test itself run at/after midnight because `today` was not the same. As follow-up report divides the lines per partner to due/overdue utilizing `today` in comparison, This resuls in different lines than expected. Forward-Port-Of: odoo/enterprise#96486
This update adjusts an internal test workaround for Gantt chart dependency behavior so automated checks remain usable after recent test framework changes. It is limited to the unit test ecosystem and does not change customer-facing Gantt functionality.
Original PR description
## Pull Request HOOT 37 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/230556 Forward-Port-Of: odoo/enterprise#96647
The Analytic Reporting grid now keeps all months visible when users hide weekends in a yearly view. This prevents confusing missing-month reports because weekend filtering is only applied where it makes sense: month-level grids.
Original PR description
To reproduce: ============= 1- Go to Analytic Reporting. 2- From the year dropdown, uncheck "Show weekends". → Some months disappear unexpectedly. Problem: ========= Weekend filtering was applied even in year range. In year view, each column is already a full month, so filtering out weekends is incorrect. Fix: ==== Adjust the condition to skip filtering when range is not "month". Weekend logic now only applies to month range grid. community-pr: https://github.com/odoo/odoo/pull/226975 opw-5078200 Forward-Port-Of: odoo/enterprise#94593
When a website is created with only the Events option selected, Ecommerce will no longer be installed automatically. This keeps the setup focused on the selected business need and avoids adding irrelevant sales features.
Original PR description
Steps to reproduce: 1. Install website module 2. Select events in configurator 3. Build website. => Ecommerce is installed, which should not as it does not make sense with only the events. After this commit: - Ecommerce will no longer be installed when the events is configured. task-4922600 Forward-Port-Of: odoo/odoo#221527
The website editor no longer shows the Countries Filter option on the Partners page, where it had no effect. This prevents confusion for website editors by keeping customer-page settings visible only where they apply.
Original PR description
Scenario: - install website_customer and website_crm_partner_assign - go to /partners - in edit mode, disable the option "Countries Filter" Result: nothing happen Cause: there is no filter options on /partners page, but the options of /customers page are targetting class o_wcrm_filters_top that is common to both page, so they are shown on /partners incorrectly. Fix in stable: change the selector to only show options on /customers. Fix in master: in website_customer, change the o_wcrm_filters_top class to o_wc_filters_top class. opw-5102381 Forward-Port-Of: odoo/odoo#228575
SEPA payment files will now mark payments as high priority only for Belgian companies. This helps companies in other countries avoid unnecessary bank fees while preserving the required behavior for Belgium.
Original PR description
Having priority set as HIGH for SEPA payments can induce extra fees (ex. in CH). This commit only sets the priority to HIGH for BE companies. task-4874217 Forward-Port-Of: odoo/enterprise#96869 Forward-Port-Of: odoo/enterprise#95420
This fix updates test setup data so products are treated as properly configured instead of missing required supply details. It prevents false test failures caused by artificially extended lead times, helping keep manufacturing planning and rental workflows reliable.
Original PR description
This PR addresses the issue where tests were failing due to unconfigured products (no vendor/ no BoM). Now unconfigured products' lead_time is incremented by 365 due to this PR: https://github.com/odoo/odoo/pull/216293 Before this fix: Products have `buy` route by default and no vendor, so they are considered unconfigured products and lead time is incremented by 365, and tests fail as any lead time refers to a date earlier than today would only affect the first period in the MPS which is not intended in the tests. After this fix: Products have `manufacture` route and there is BoM, so they are considered configured products and lead time is calculated normally from BoM which is 0. Task-4779057 Forward-Port-Of: odoo/enterprise#88766
This update corrects an automated test so it no longer depends on Belgian localization behavior that may not be present in smaller app builds. It helps keep Peppol-related quality checks reliable without changing customer-facing features.
Original PR description
This commits fixes test we previously added [1]. In Belgium, the Company Registry (0208) and the VAT number (9925) can be computed from each other (`0208:0400000000` <-> `9925:BE0400000000`). [This compute](https://github.com/odoo/odoo/blob/0d8aadb2db7f10d439e10f222ec0ab6dcfab3672/addons/l10n_be/models/res_partner.py#L13) is actually only available in l10n_be, while the test rely on it to deduce the expected EAS, and therefore fails on single Apps builds. [1]: https://github.com/odoo/odoo/pull/230880 [runbot-error-233343](https://runbot.odoo.com/odoo/runbot.build.error/233343)