Main Flow Tour Mobile shouldn't require a specific `user_agent` as it
targets a small screen and not a mobile platform (iOS, Android...).
Actually, during refactoring of the tours (odoo/odoo@3a798039d6),
a confusion was made between the legacy `isMobile`, which represents a
small screen (cf. `env.isSmall`) and `isMobileOS`, which targets
"mobile" platforms (ie. iOS, Android...) independently of the screen size.
This commit applies the proper condition (isSmall) for the tours
management and removes the useless `user_agent` property. It also
removes the logic added to support custom user_agent in the Chrome
automation for testing.
closesodoo/odoo#116186
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Chrome 111 enabled checking of websocket origin: if the WS connection
sends an Origin head which is not whitelisted with the new
`--remote-allow-origins` switch it is rejected.
Turns out websocket-client (amongst others) *does* send an `Origin`,
which trips the check, and means tours immediately break when trying
to run them as Odoo's test harness is unable to connect to (and
control) the devtools.
Suppress sending `Origin` to fix the issue.
To make the watch mode work, set `--remote-allow-origins`: since we
specifically only bind the devtools to the loopback
address (127.0.0.1) whatever issues this plugs are unlikely to affect
us. We might eventually want to change the behaviour of the watch
feature for UX reasons and remove this in the future though, either by
working through the non-ws remote inspection (`chrome://inspect`) or
by having the `watch` mode run in a normal browser directly instead of
having a browser connect to a headless browser.
Chrome 111 changeset: https://chromiumdash.appspot.com/commit/0154caeefc74530d5cb57ce71608beb1b77bca39
Chrome tracker issue: https://crbug.com/1422444closesodoo/odoo#115067
X-original-commit: 47a02b3924c3e4d1690e336fdd764383393ee378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
document_ftp, website_instantclick, pad, pad_project, note_pad, pos_cache is not currently existing in the addons, removing the non existing modules from the BLACKLIST dictionary.
closesodoo/odoo#107213
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The test-file is used by some dev to run all test classes from a file.
But test-file is always post install and doesn't always have the same
behaviour of a normal test execution.
This commits modifies the module test tags behaviour to be able to
give a file.
closesodoo/odoo#113850
X-original-commit: 5aff8cf22ab0cbac7a9a3cebf39860f55617f79e
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Odoo Test environments requires to modify many parts of the unittest
TestCase, Suite and Result.
The main initial reason is to **avoid to postpone result at the end of
the test suite**, because even if it is convenient to have all errors
visible after the tests in some case, odoo logs adds information during
the execution that can be useful to debug when a test fail, to have
context for an error. (see **OdooTestResult**)
We are also fixing the stack trace comming from a unittest and since
there is no proper way to hook inside the TestPartExecutor, a dirty hack
injects anoter result on the outcome to manage the error and complete
the stack trace. This was also a way to avoid to postpone subtest logs
at the end of the test case (see _ErrorCatcher)
`_feedErrorsToResult` was used to test the test suite behavior since
there are many customization and this is quite fragile, especially if
unittest changes behavior in other python version.
**Python 3.11** introduced python/cpython#664448d8 That, in a way, goes
in the same direction of the changed introduced with _ErrorCatcher:
immediately feed errors to resut instead of postponing it. But this also
removes `_feedErrorsToResult` that was used to test this behaviors, as
well as other ones.
Since odoo should remain multi-version, this amount of changes on the
initial behavior become to complicate to keep cross-version and the
(already in our mind for a while) solution to **vendor unittest** will
help to simplify most of our test code base.
This commit modified the vendored unittest files to simplify them as
much as possible to suite our needs.
Since the runner is still the unittest one, we need to inherit from
unittest.Testcase in order to have the right type.
This also means that we still have access to all TestCase methods
without overriding them all. This is convenient for assertion methods as
an example but the initial idea is to vendor our own version of TestCase
to avoid having trouble to adapte our miscommunications to future python
versions. A trade-off must be done to chose what should remain in our
code base. The idea is to keep logic closely linked to our changes in
our code base, mainly around the run method, but also addClassCleanup
wich need to be vendored for python 3.7, but assertions methods are
independent. Any logic can be moved fom unittest to our
vendored version in the future if needed.
X-original-commit: 9a5d1ea54be49e4cc8208c33e76a6bbd2414d5d0
Part-of: odoo/odoo#113850
Vendor some unitest file before modifying them in next commit
Chosen files are suite, case, and result since they are working together
and are the most modified classes in odoo.
mock, signals, runner and utils will still be imported from unittest.
X-original-commit: 742d165b9a1bff23deb736dee6b266c76f3ce727
Part-of: odoo/odoo#113850
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Warnings show up when using a recent pylint. It's only a fraction of
what e.g. pycharm flags as "local variable might be referenced before
assignment" but seems a good idea to fix anyway in prevision of
possibly eventually updating the reference pylint.
closesodoo/odoo#107968
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit adds (in comments) the necessary code to (more) easily
detect memory leaks in the qunit test suite. Running the test with
those lines uncommented would log information about the heap size
after each test module and the delta of the module, after garbage
collecting.
Useful regexes to extract information from the log:
```
remove lines not containing "delta: ":
`(^.*?delta: .*$\n)|(^.*$\n)` => $1
extract deltas:
`.*suite (.*) -.*gc: (\d+).*delta: (-?\d+).*` => $1,$2,$3
```
closesodoo/odoo#108620
X-original-commit: 0d5cb1659468f01f1b6f88deca0b46c1810111b0
Related: odoo/enterprise#35224
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The motivation of this commit is to get a correct pathname on an
ir_logging when a test fail .
The main issue comes from subtest since an exception inside a subtest
will have only a partial traceback, not containing the line triggering
the error in the test method.
This can also affect debugging since a part of the stack is missing.
See pull request for more informations
X-original-commit: 2b6a8bc79529578ecd21bbb0fd4fe452f28d7cd7
Part-of: odoo/odoo#108202
Currently the `not like` and `not ilike` operators are available for the Odoo domain in Python but not in JS.
This commit adds these two operators in the JS Odoo domain too for better code clarity. For instance:
`[('fiscal_country_codes', 'not like', 'AR')]`
instead of
`['|', ('fiscal_country_codes', 'like', 'AR')]`
Part-of: odoo/odoo#106221
Enable the test for payment modules, as we want to test their install/uninstall.
But disable the test for the deprecated payment modules, which can only be installed
through command line since 16.0.
closesodoo/odoo#107349
X-original-commit: ae559ee083723ff16ec78d93ec781202686553e6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Pregenerate doesn't work for rtl languages. It shouldn't be a problem
but it was discovered that pregenerate run during upgrades leading to
errors
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1314, in preload_registries
env['ir.qweb']._pregenerate_assets_bundles()
File "/home/odoo/src/odoo/16.0/addons/website/models/ir_qweb.py", line 180, in _pregenerate_assets_bundles
_, _, _, id_unique, name = bundle_url.split('/')
ValueError: too many values to unpack (expected 5)tore the set of known environments as it was at setUp
```
This is because the rtl is an extra in the url breaking the logic.
Pregenerate is mainly usefull for tests on runbot
(or running tests locally), to speedup httpcases
avoiding generation at each page load.
IntegrityCases are postinstall but don't requires generating assets, or
at least no so often meaning that we can avoid the pregeneration in this
case. It should also avoid losing some time on pregeneration since it
is not useful.
This new logic only pregenerate if we have at least one HTTPCase in the
test suite. This should also speedup local testing when starting
non http post_install tests.
closesodoo/odoo#107107
X-original-commit: 43a5c17088707eec134d54ccf9341e86859f88c7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
`DOM.querySelector` will generally return a `nodeId` of 0 when no node
is found, however there is a small window during which the document
can apparently get collected (?), which leads to an error
Could not find node with given id
which can break otherwise successful builds (cf 20832402 / staging
60731).
Handle errors from the pipeline as if the node had not been found,
though the matter was not fully investigated so it's possible this
explanation is incomplete or incorrect.
The CDTP documentation does not document the failure modes for either
`DOM.getDocument` or `DOM.querySelector`.
closesodoo/odoo#105734
X-original-commit: 5ef975f75cf8044e7dcd67f403ca11058630c85a
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously, the context passed in onchanges calls after a o2m modification in the form view were the one of the parent object, whereas it should have been the context defined on the o2m field itself
closesodoo/odoo#103081
X-original-commit: 31ee570d17db2f5e3e2ff6877a7634ab9be12492
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
During the tests, many attachment can be created and unlink.
They will be eventually cleaned up if the cron is ran but this is
usually not the case during tests. The disk usage can increase to reach
more than one 1 Go when design theme is installed.
This can lead to unnecessary big database dumps.
This is also a problem on odoosh where the filestore max size is limited
to 1Go.
The gc should be quite fast if nothing was changed since it will just
check the content of an empty directory.
The method is made accessible in the test case in order to be able to gc
on demand. This may be useful in the test_01_crawl_every_themes that
can generate around 600~ Mo of attachment in the loop.
X-original-commit: 187309f5a39f8fef9b07959fd73475fd6732efb3
Part-of: odoo/odoo#102502
When 2e8647bf16 converted the browser
runner to a more reactive / evented system, one bit was missed in
"wait_code_ok": concurrent.futures.Future raises exceptions on various
events, such as tour timeouts. Because those exceptions were not
caught (or just ignored) the code which takes screenshots was
bypassed, leading to a lack of screenshots on tour timeouts (and a few
other rarer errors), making debugging more complicated.
The error reporting was also not ideal as `wait_code_ok` would raise
an unexpected (by its caller) `TimeoutError` rather than
`ChromeBrowserException`.
Fix those two issues, should hopefully makes these occurrences clearer
and easier to diagnose.
closesodoo/odoo#102403
X-original-commit: 974217968ea970330946c5184bd3b3550ec3cde3
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Currently the exception is not logged using the logger meaning that the
only indication of the failure is the "module not loaded" error message.
Catching the exception to log it the proper way will help identifying
the cause of the issue, mainly for uninstall tests.
closesodoo/odoo#100431
X-original-commit: b16f850d9aa438aea91b8cbd7c33692e1e1b2f90
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since #99912 logging an error message doesn't always end qunit tests.
This was mainly to allow to failfast logging qunit errors earlier
without stopping the tests in order to test all qunit anyway.
The logic was to have an end message that stops the test.
Unfortunately some errors will prevent the qunit suite to start
and the test will wait a 1800 long timer. An example was because of
a Missing dependencies. https://runbot.odoo.com/runbot/build/19306352
This new approach will avoid to stop only if the message looks like a
qunit failure and the final message is not there (to be sure).
closesodoo/odoo#100238
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit changes the node modifiers domain evaluation in the Form test class to allow strings.
Domains as strings are used by the web client to evaluate special values such as 'uid'.
Part-of: odoo/odoo#99735
Right now the qunit will log all results at the end.
This means that the runbot may wait for all qunit before detecting the
failure.
This also mean that all failure are in one ir.logging on runbot, making
the automated parsing difficult if multiple modules fails during the
same build.
We could also log all failure immediately, but grouping them my qunit
module will avoid duplicating logs for linked causes (one failure
leading to a `Expected %s assertions, but %s were run` message)
closesodoo/odoo#99912
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The name "Payment Acquirer Test" of the acquirer bundled with the module
`payment_test` is confusing. It is actually the only acquirer that
doesn't connect to a test API, and its purpose is not to make test
transactions but to showcase the integration of other apps (Accounting,
Sales, eCommerce, Subscriptions) with demo payments.
Hence, the module is renamed to `payment_demo` along with its data and
technical keys to better make the distinction between acquirers' test
environment and demo payments.
task-2853481
closesodoo/odoo#99397
Related: odoo/upgrade#3846
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The unconditional setting made a lot of sense before the new test
tags (95b4f2ab4b) when the test module
was a test tag: filtering the module out of the existing tags would be
difficult.
However since then the tags should only contain "actual" tags,
therefore inheriting tags (and tagging mixins or Common cases) should
not be an issue anymore.
Part-of: odoo/odoo#98814
When profiling an HTTPCase the only result will be the starting of the
browser and the ready/ok code. All requests are in other thread
and are not profiled.
HTTPCase profiler will now patch the _get_profiler_context_manager
in order to enable profiler on all requests during this time
closesodoo/odoo#99119
X-original-commit: 77d110de242c8b8e9b0f09dcecad25c203f32535
Signed-off-by: Julien Castiaux <juc@odoo.com>
Some tests are randomly failling because /web takes more than 10 seconds
to load. A future pr will speedup /web but waiting for that a small
bump of the timeout should help.
closesodoo/odoo#99198
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The qunit loading is now arroud 15 seconds, breaking sometimes because
of the 15 seconds timeout.
A quick and dirty fix increases the timeout to 20 (freeze time)
An deeper investigation is needed to speed up this page.
Pregeneration of assets bundle may help
closesodoo/odoo#99163
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Currently e.g. syntax errors during the import are logged as
exceptions but they don't fail the loading / testing.
Update the loading using more modern loading APIs, in order to not
catch them at all (let them bubble up normally), and instead just
find *IF* a module has a tests submodule before trying to load
in (LBYL).
Fixes#80198closesodoo/odoo#97957
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When test are skipped, we don't have any information of why.
It seems important to log also the reason, it can help
developers to find the source of issues (example: when your chrome
doesn't the devtools active: you just know that test is skipped, but
don't know why)
closesodoo/odoo#97481
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since 54ea956490 the form view has an
"urgentSave" fallback when the page is unloaded (tab closed, page
navigated away from, ...).
In tours, this translates to new network requests being performed
during the browser cleanup, possibly chaining further into more
network events.
Flag these tours as incorrect (by making them fail if we find a form
in edition mode after receiving `"test successful"`).
Adjust testing of http cases because I've added an empty line between
the signal and the actual message for better readability on complex
error messages.
Also provide opt-out, as for some tours it's difficult to impossible to
truly fix them: the `allow_end_on_form` class attribute can be set to
`True` in order to disable the new behaviour.
To implement this, update the browser runner receive the test class
directly (rather than just the test class' name) for more
introspection flexibility.
Part-of: odoo/odoo#96517
Currently, when enabling watch mode on a tour the tour's timeout does
not change. This is usually an issue because:
- watch mode makes tours a bit slower, so they can timeout even
without doing anything
- trying to diagnose what's wrong, it's common to add check steps with
a long timeout or even a `debugger` statement, which trips the
python-side timeout and kills the tour
To avoid needing to remember to update the timeouts (then revert them
afterwards), just bump the timeout to 1h by default, or 10x the
original time for very long tours (e.g. qweb test suite, which
currently has a 30mn timeout).
While at it, forward the watch mode status to the client via the QS,
so we can eventually make use of it for one reason or an other.
closesodoo/odoo#96994
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Auto retry can be usefull to avoid breaking a build because of a
small tour or query count, but for long tests like qunit, this can be
painfull when a real error is triggered.
This commit proposes to disable autoretry on demand for some tests
to solve this issue.
This may be applied on all tests longer than a few seconds.
closesodoo/odoo#95440
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit Chrome's "touch mode" was enabled in both desktop and
mobile-like tests suite (when run headless).
To better match real usecases, this commit adds an option to
enable "touch mode" only in mobile tests suites; keeping it disabled in
desktop ones.
Part-of: odoo/odoo#95924
Uses a dedicated logger (for easier filtering / silencing) for
results output, and provides rough (module-level) stats in INFO but
detailed (test-level) in DEBUG.
Also updates the global query counter (`odoo.sql_db.query_counter`) to
update after each query rather than on close: with test cursors the
actual underlying counter is only rarely flushed.
closesodoo/odoo#95420
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously, the test runner would evaluate an expression to check if the
browser test that is about to be run is ready, but before the test is
ready, this expression may be invalid as the variables used in the
expression may not be defined yet, causing a ReferenceError to be thrown
by Chrome.
In Chrome >=102, errors that are thrown when writing code in the console
or by using Runtime.evaluate over CDP are thrown in the context of the
current tab, which means that they trip registered error handlers in
that tab. In Odoo, this means that we show error dialogs with the
traceback.
In the tour manager, when we are looking for an element to trigger, we
only look for that element inside dialogs if there are any dialogs open
(unless the in_dialog option is false on that specific step). This means
that if an error dialog is open, most tours will fail (which is actually
what we want).
In order to avoid opening a bunch of error dialogs while waiting for the
tour to be ready, we simply wrap the ready expression in a try catch so
that it doesn't throw an error, and simply returns a undefined until the
tour is ready instead of throwing a ReferenceError.
closesodoo/odoo#95635
X-original-commit: 3872dbd63233d4c6d961a3cd896b84e4301a1f84
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since #91909, the settings form view is tested with different levels
of access rights, post install.
But when the test is run with only the base module, it crashes because
the settings view specified in base is empty, without any field.
On save, the test form reads the view fields, but read fallbacks on
all fields if no field is specified, and it breaks when we try to
compare the read results to the fields requested (empty).
This commit skips the read when no fields is present in the view.
closesodoo/odoo#95340
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Raphael Collet