Tuesday, April 15, 2025
5 changes · master
Resolved issues and error corrections
Automated web tours are now disabled consistently during tests, preventing unrelated onboarding tours from interfering with test runs. This makes test results more stable and reduces false failures when validating Odoo changes.
Original PR description
Any time a tour is run, the web client can decide to run an onboarding tour at the same time. With the tests being run without demo, this becomes *very* likely, as the presence of modules with demo…
Any time a tour is run, the web client can decide to run an onboarding tour at the same time. With the tests being run without demo, this becomes *very* likely, as the presence of modules with demo data is one of the base conditions for `_compute_tour_enabled`.
Some tours were fixed ad-hoc when trying to get everything working without demo, but the issue is basically universal, it just doesn't show up in all cases (possibly through side effects of other modules) e.g. before this change
- create a database with the modules `auth_totp_mail` and `website_event`
- run the test `/auth_totp_mail:TestTOTPInvite.test_totp_administration`
The test fails with
Error in schema for TourStep
[...]
Invalid object: unknown key 'noPrepend'
This is because website does a mess in the tours, adding its own magic tour keys which are not handled by the generic tour framework, but when we try to run the tour `totp_admin_disables` the client retrieves the active onboarding tours, finds `event_tour`, and starts running that[^1] apparently without the magic from website. Which reveals that the tour is being loaded / running even as we're trying to run an other tour.
Fix by patching `tour_enabled` globally, and remove the ad-hoc unsets.
[^1]: via the `session.current_tour` case of the tour serviceFixes an issue in the web tree editor where removing the only condition inside a subgroup could leave an invalid empty group and cause errors. The editor now cleans up empty groups automatically, making filter/domain editing more stable for users.
Original PR description
With https://github.com/odoo/odoo/pull/203931/commits/2e1e4ba478c6f0595614632ddc813a37ba05044b, we no more have to restore virtual operators, we simply keep them in the tree editor as long as the domain held by the parent is essentially the same as the one represented in the tree editor. Thus without noticing it, we have introduced new possibilities in the tree editor: it is now possible to have two successive connectors with the same values (something we wanted) or have a sub connector with a single condition in it. In the latter case remove the condition leads to problems/crashes: a connector with no children does not really make sense in a domain. So we have to normalize things properly.
This fixes a startup issue in the import tool when optional spreadsheet libraries are not installed. It helps ensure the system can still load cleanly instead of failing while preparing supported file types.
Original PR description
Moving stuff around as part of #172761 I forgot the `xlsx` assignment if `xlrd`'s import fails (if xlrd is not installed), which leads to an error when defining `FILE_TYPE_DICT` if `openpyxl` is not installed either.
This change updates internal tests so they no longer depend on a product variant setting that may not be enabled. It helps keep automated checks reliable without changing customer-facing sales or manufacturing behavior.
Original PR description
Issue started popping up on runbot on March 26th, after the change to demo data in tests, so this is likely because demo data enabled the `group_product_variant` somehow on the current user. The…
Issue started popping up on runbot on March 26th, after the change to demo data in tests, so this is likely because demo data enabled the `group_product_variant` somehow on the current user.
The issue of these tests is that they try to set the `product_id` on an `mrp.bom`, but in the view `mrp.mrp_bom_form_view` which they auto-resolve to the field is declared as:
<field name="product_id" groups="product.group_product_variant" context="{'default_is_storable': True}"/>
<field name="product_id" groups="!product.group_product_variant" invisible="1"/>
Thus without variants management enabled the field is not visible and can not be set, triggering an error.
There are two possible fixes for the issue and both seem to work fine:
1. Enable variants for the user.
2. Don't set the `product_id` on the bom.
While the test probably originally used (1) implicitly, the tests don't seem to do care about variants at all, they only seem to manipulate single-variant products. Thus we can just stop setting the `product_id` and rely solely on the `product_tmpl_id`.
https://runbot.odoo.com/odoo/error/161643The web sample data system now handles reports or views that ask for highest or lowest values. This prevents automated test failures and helps demo screens continue showing placeholder data reliably.
Original PR description
The click-all tests were failing for the `fleet.vehicle.odometer.value` field when the aggregator was set to `max`. This was due to the Sample Server implementation not supporting `max` or `min` aggregators (see https://runbot.odoo.com/odoo/error/161783). This commit adds support for `max` and `min` aggregators in the Sample Server. The implementation mirrors the behavior of the `sum` aggregator, as the primary purpose of the Sample Server is to display dummy data to the user. This keeps the implementation simple while resolving the test failures.