When testing cron triggers, it is common to get the newly created
triggers in order to validate they exist and are scheduled are the right
moment.
This new helper is a context manager that capture all triggers or
triggers created for a specific cron. The created triggers are
accessible via the context's object `records` attribute.
The various tests have been updated so they use that new helper.
closesodoo/odoo#68163
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Raphaël Collet <rco@odoo.com>
We have some tests in odoo/upgrade that are sensitive to the order on
which they are executed. Specifically: IntegrityCase tests need to be
run after all UpgradeCase tests across all Odoo modules.
To support this we implemented a sorting mechanism for tests based on
the test_sequence class attribute. This is intended to be used by meta
cases, not by individual tests.
closesodoo/odoo#66521
Related: odoo/upgrade#2184
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In some situations, like during tests on runbot, the data-dir location
may vary.
With this commit, the `data-dir` CLI argument is added to the
test_module_operations script.
closesodoo/odoo#66492
X-original-commit: 781c91784a0a997967a0152dca2c59a0cb2bab74
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This should be a smarter and properly reliable version of #42071: in
that, the runner requests a port, closes it, and gives the port to
Chrome. However this apparently turns out to be less reliable than
hoped for and the port we just released can immediately be picked up
by somebody else (the original PR assumed the allocation of ephemeral
ports would be random or FIFO but that may not be the case, especially
inside containers).
This uses the same technique of requesting port 0 so the OS allocates
one, but it's Chrome requesting & immediately connecting so there
should be no race condition possible, and we keep the property that as
long as ephemeral ports are available Chrome will be able to open one
without conflicts or overlaps.
This leaves the issue of *retrieving* the port chrome got. Thankfully
it turns out we use a custom user-data-dir in which case Chrome writes
the port it got to `$DATA_DIR/DevToolsActivePort`[0]. Despite the
file's name it *also* contains the path for the devtools endpoint so
we need to only read the first line (rather than be able to read and
intify the entire thing).
Wait up to 10s before giving up entirely, and wait 100ms between each
check for the file's existence: on my machine without significant load
the file appears after 80 to 150ms, waiting up to 90ms seems ok (it's
not like we're in a super hurry as tours tend to be pretty long).
Other paths explored before moc used his eyes and brain and found out
about DevToolsActivePort:
* Chrome prints ws URL on the stderr, however because we don't know
how much garbage Chrome might send there we need to send it to a
continuous sink otherwise Chrome *might* end up blocking on its
stderr because we're not reading from it. This turns out to be a bit
of a mess of processes or additional threads.
* xdo suggested we check what ports Chrome listens on using something
like netstat/ss (turns out `psutil` has support for that OOTB),
which worked great except on WSL (where it didn't work at all), and
the future-proofness was a bit questionable as Chrome might add
other servers in the future.
* fme suggested using socket activation support[1] and passing in the
port we'd opened without closing it, which would really have been
ideal, however it turns out it was removed a few months later when
chrome added pipes support[2], which was a pain to realize as chrome
doesn't exactly do any useful error reporting (so unknown options
just disappear into a void to be never seen or heard of ever).
* And while the pipes system[3] has *serious* positive attributes
(even lower initialization overhead, we could remove the websocket
dependency, also avoids wasting sockets though that's not too much
of an issue here) it would require rewriting a lot more than just
the initialization as it uses its own logical protocol
(NUL-terminated JSON). TBF most of the messaging stuff is properly
contained into just a few `_websocket` methods but still...
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=624837#c4
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=624837
[2] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3#message-ab7415a7db7b94787300d987216e9ce60db47bc2
[3] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3
opw-2378464
closesodoo/odoo#65195
X-original-commit: b679d97a83f1ac898ee0916e92a5b440702bdcdf
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
Co-authored-by: Christophe Monniez <moc@odoo.com>
Allow a False email as valid valid. Generate an email only if not given but
keep void values.
Ensure company_id / company_ids match, notably to ease creation of users
in a multi company test environment.
LINKS
Task ID-2421795
COM PR odoo/odoo#63677
X-original-commit: 21999058800957a08c5e129c527afe6b84812a8a
Bug
===
Sometimes, the registration testing tour failed.
The bug can be semi-deterministic if we add a "sleep(1)" in the endpoint
"/event/<event>/track".
Reason
======
The reason for that is the service worker. It will pre-fetch all the
links in the page (see "prefetch-pages"), so for the "Online Reveal"
we will pre-fetch ~100 pages... If the server is slow, it can cause
issues.
If one endpoint takes some time, all other HTTP requests done by the
service worker will be waiting for it.
So, at the end of the testing tour, the service worker will continue to
make HTTP requests (because it makes the request sequentially) and so
some threads will still be created after the tour.
Even if "_wait_remaining_requests" is called to wait those threads, as
the service worker is still running, it will still continue to make HTTP
requests, creating new threads...
Fix
===
The solution to this issue is to kill the service workers of the browser
when we stop the tour before waiting for the end of the "HTTP request
threads".
Task 2381066
closesodoo/odoo#62827
X-original-commit: 6d08408a33880221b28f0f8a81d699825d927a48
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The now unique class behaves as the former class `SavepointCase`. It is
now up to the developer to use `setUp` or `setUpClass` for preparing the
tests.
This commit fix the "Unsupported M2M command 1" raised `Form` helper.
The `onchange()` method will in fact emit UPDATE command for many2many
fields when the value submitted an the one in database has changed
(this is the case for example for nested m2m in form views)
OPW-2044631
closesodoo/odoo#59943
X-original-commit: 76bd8208a416cefab6becff9f2d7204c7d196201
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier ALT <xavieralt@users.noreply.github.com>
When the sceencast argument is used to produce a video file of failing
tests, the framerate is computed with a KISS average.
This results in a misleading video flow. For example, if a tour step is
stuck, the average could show a smooth transition instead of the reality.
With this commit, the real duration of frames are used to produce the
video. The result is a more realistic video flow.
The configuration text file used by the ffmpeg concat demuxer is kept
alongside with the video file so that it can be used for other purposes
(e.g.: parse the durations to be used by a video player on runbot).
closesodoo/odoo#58280
X-original-commit: 58eb6a4565c024077557fa2de83fdf831e5ef026
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
* override `onchange` in res.users in order to properly generate and
send the reified group fields alongside the rest: while default_get
sets them up, those fields then get stripped by the onchange
machinery as they don't actually exist on the model
* add a test to check for it
* fix SSF in relation with the new default/onchange system
- because fields may not actually exist on the record,
`record_to_values` needs to `read` the record data rather than
directly access the recordset: the recordset likely will not
know about fake fields
- after the initial onchange has run the form must be filled with
falsy values in case the onchange has not sent defaults for
everything
- on creation, all fields in the form should be considered modified
Task 2341153
closesodoo/odoo#58152
X-original-commit: f8658f229180a595d69cd6daefeded082c7f64ea
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`
But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`
This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.
[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54closesodoo/odoo#56612
X-original-commit: 782534a429f10e7b114c838687d38aa4080a920c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
When creating a new record, the client calls `default_get()`, completes
the returned values with `False`, and calls `onchange()` to apply the
onchange to the defaults.
Optimize the double round-trip by integrating `default_get()` inside
`onchange()` for the first call. The method is called with an empty
list of fields, and usually no field values, except for records in a
one2many field. In this case, `onchange()` does both steps above.
Task 2261084
* remove useless OdooTestRunner
* don't log results & time per-file, log a module-level tally instead
* add number of tests to post-test results
* generate a single test suite per module (see note)
* use the previous item to split out the at_install test-running in
two steps: generating the suite for the module then running that
suite, this way for modules which have no test, or for
which all tests have been deselected by test tags, we can avoid some
of the setup necessary to prepare for running tests but possibly
quite expensive (e.g. `setup_models`)
Note: single test suite per module
I wanted to stop creating a test result for (essentially) every file
in the module, however because of the class-level ``addCleanup``, a
TestResult can't be reused by independent suites:
In order to run class-level cleanup, the test suite checks between
tests if the test it's *preparing* to run is in the same class as the
last test it ran, and if not applies the class-level cleanup.
The problem is that the "previous test class" is stored on the result
object, which is never cleaned up, and the "between tests" check is
really performed *before each test*.
This means when reusing results across suites it will run the
class-level cleanup at the end of one suite and immediately at the
start of the next, which will cause issues if class-level cleanups are
not idempotent (thankfully ``TestTestCursor`` has a non-idempotent
``tearDownClass` which let me discover the error).
Possible fixes are:
* don't reuse results
* clear the relevant states / attributes between suites
* put individual suites in a Big Suite for running
The latter seems simpler: just create a single suite for the entire
odoo-level module instead of creating one suite per test module.
Note to the note: the case of nested suite is taken in account, the
"end of suite" cleanup only runs at the end of the top-level suite, so
technically we don't have to unwrap suites for *that* purpose, we're
doing so in order to filter the test cases inside the suites. But
maybe we could integrate this feature to the suites themselves...
closesodoo/odoo#55185
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
That's a not-very-useful subset of OdooTestResult, so:
* make results merge-able (aka add ability to update a result with the
contents of another)
* remove support for test data files, and transmission of the
assertion report thing through the data-files loading
* replace "legitimate" uses of assertion report by test result
* have run_unit_tests manipulate and return a result instead of weird
flags & ternaries
The browser itself would get mostly cleaned up between tours, but the
session object would not get cleaned, and apparently in some cases
that could lead to an incoherent session: a tour would add data to the
session which the next tour (logging in as a different user) would
not (fully) override, leading to a session inconsistency and a Session
Expired exception during the tour.
Fix by not storing the session on the test object, the session is
created during authentication then set on the opener & browser.
Allows accessing various keys, especially whether this is an
interactive login or not.
Also have the xml-rpc `login` delegate to `authenticate` instead of
having its own half-assed implementation.
And remove some dead code: as far as I can tell, Session.authenticate
is never called with a uid.
Thanks to this setup, we will be able to run the tours independently to any demo data.
To do so, the HttpSavepointCase is born to do the same as HttpCase but with a setUpClass.
--task: 2290120
Issue is specifically in the case of an onchange removing a record in
an o2m in an o2m (so a sub-o2m) if loading an *existing* record in the
SSF: since the server pretty much only returns a REMOVE_ALL followed
by the records to keep or create, conserving the removal information
requires diffing the value currently stored in the form and the result
fo the onchange.
Diff which was properly done for top-level o2ms, but not for the ones
below that (apparently forgot this bit when improving support for
nested o2ms earlier this year).
X-original-commit: 177d009541cca589c6ebb85fc051b893ec001536
Technically removing the entire thing if it's not one of the special
cases is a form of cleanup I guess, but that seems a bit brutal and
counter-productive. So that function should *probably* return the
input value if it's not a type which requires special processing.
closesodoo/odoo#51531
X-original-commit: b42994c87dce12c5ba22943f6cbe00240fe43138
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The SSF had pretty much punted on nested o2m as that's... not usually
a concern because few people are insane enough to put o2ms in their
o2ms in their views. And also because even if somebody did, sometimes
nothing would break because it turns out to be pretty difficult to
actually get into *using* those things.
MRP managed to do it though, and repro-ing required copying over parts
of mrp.production and then understanding why it didn't fail:
* obviously needs an o2m (f1) which contains an o2m (f2), in the
view (an invisible tree inside a visible tree)
* needs an onchange which somehow updates the sub-o2m
* needs to actually trigger an onchange on the root form for f1,
meaning f1 must be a dependency of a compute field or something (here
I just marked every damn field as on_change as the optimisation of
"don't call onchange when there's no need to" doesn't matter)
Also needs to be working on an existing record with existing
lines *and sublines* as the issue occurs with records to update.
The issue here is that `_onchange_values` would clean up f1 e.g. send
nothing for unmodified entries, and only send modified fields
otherwise, but it would only do so for the toplevel, meaning the
sub-level would not go through this step, and could send UPDATE
commands with an `id` field (set to the original value but
still). This would then proceed to blow up while loading the record,
as id fields are not writeable.
The fix is to perform `_onchange_values` recursively. Do that using a
separate helper in order to avoid blowing up on override and whatnot,
or faffling about with weird branching to get the "default" values in
case they're not provided, the root function can get all the relevant
bits and call the helper with them, then the helper does that setup
internally and calls itself directly.
An other issue I stumbled upon when investigating is a similar problem
on *save*, due to an implementation detail of the SSF: UPDATE commands
are fetched lazily.
`_values_to_save` took care of "hydrating" all update commands (and
validating and filtering them) of modified o2m fields, but as it would
not do so recursively a modified f2 would not get properly hydrated
and filtered, and could try to write `None` onto existing records.
closesodoo/odoo#51350
X-original-commit: 3dfb4cfad849936748cc6a5b8f712e100461a86f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
From time to time (frequently on Mac OS), the Chrome tests are failing
because there is no tab found in the browser instance.
It seems that in some circumstances, the browser is started but the tab
takes some times to appear, for that reason, the tab information is not
available in the first json commands.
With this commit, the json command is issued multiple times with an
increasing delay until the desired key is found in the json answer, or
until the timeout is reached.
closesodoo/odoo#50784
X-original-commit: 4b12643abc6b8ba34f14e468e8d7760bc2db385b
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this change, the SSF would read from the record after
creation but wouldn't do so after a write.
This doesn't conform to the behaviour of the web client (which does a
read() after saving a form), and means the effect of field
inverses (when the dependencies of a writable field are also in the
form) or overrides to write wouldn't be visible afterwards.
It's always possible to just re-create the form from scratch, but the
intention has always been that the form would work correctly after a
save.
closesodoo/odoo#50363
X-original-commit: 45398c09c0231e61b83d378d5939ec12d7465844
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Screencasts were saved in the right directory (screencasts_frames_dir)
but the given path for ffmpeg was wrong (screencasts_dir) and it wasn't
possible to read theses files to make the video.
After this commit, we use the screencast_frames folder to read files.
Steps to reproduce:
Execute Odoo with these additional command:
--screencasts "folder_of_destination" --test-enable (with a failed JS test to produce a screencast)
X-original-commit: 0c0b7a656388d65de15796f07a3f4cc93028f1d7
odoo/odoo#46024 improved the serialisation of arrays being logged (in
order to get more relevant data than just `Array(5)`.
However, chrome apparently serialises *argument* objects as array-like
with a few nits, namely that arguments have non-numeric properties
which don't necessarily have a value associated with them.
The array formatter / converter assumed all properties had a value,
resulting in the process crashing rather dramatically.
Filter out non-numeric properties on arrays.
closesodoo/odoo#49418
X-original-commit: 5ff1e41c98f042fd13a1762977cc76604231dfd4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In case a controller with a relative url return an absolute link
the current crawler follow the redirect and all external link of this
external url too.
Now we don't follow redirection if it is on an other netloc that the
current one.
Part of https://github.com/odoo/odoo/pull/38950
task-2087641
This warning should only appear when Chrome is used.
closesodoo/odoo#48009
X-original-commit: 013b32f000520217af17b6e1ffe1872ec97afdf0
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
With this commit, a new script "tests-uninstalls.py" is added in order to
test module uninstallation.
This script is a kind of standalone tool. It uses odoo as a library but
the odoo server is not started at all.
In its standard invocation, it tries an install/uninstall/reinstall
cycle for each all module found in the specified database.
By specifying '-U', it only tries to uninstall the comma separated list
of modules following the argument.
Be aware that this tool, will alter the database against which it was
invoked.
Co-authored-by: Raphael Collet <rco@odoo.com>
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closesodoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
The method `recompute()` should not recompute fields on new records.
This is both a speedup (those recomputations are not necessary), and
fixes an error following an `onchange()` (a field recomputed in an
environment with the wrong context.)
OPW 2184998
closesodoo/odoo#47545
X-original-commit: fa852ba1c5707b71469c410063f338eef261ab2b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The old path would just return e.g. `Array(2)` for an array of size 2,
which is not very useful when trying to see if an array's contents are
relevant to an issue.
Turns out arrays are serialized pretty much exactly like objects
without a subtype, just with property names being indices instead of
keys. So add a case which formats such remoteobjects as
array-literal-ish.
closesodoo/odoo#46056
X-original-commit: 6d5639024fa0f7501efe836e5571cd45bb46b123
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since Chrome version 80, the V8 javascript engine is using an new
pointer compression feature [1]. This features tries to reserve more the
4GiB of memory. As a consequence, during HttpCase tests, odoo tries to
launch chrome headless in a subprocess but fails because of the
memory-limit-soft.
With this commit, the Chrome browser is spawned in a forked process
that removes the memory limit.
Also a new Chrome CLI switch is used to prevent crash reports to be sent
to google.
[1] https://v8.dev/blog/v8-release-80closesodoo/odoo#45859
X-original-commit: 726d9c50720c2d3c9e617e998ed0dcd12272a271
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
During an HttpCase, when the Chrome browser starts, it may happens that
the websocket is unreachable. In such a case, the stop method is called
and tries to stop the browser gracefully by sending a `Browser.close`
through the websocket ... which is not reachable.
The result is a confusing traceback. With this commit, nothing is sent
is the websocket is not available.
Moreover, the `sigxcpu_handler` attribute is used in the stop method but
not yet declared. Fixed by moving it before calling the _chrome_start
method.
X-original-commit: 0d156fd3bc114b40680ca5aa0456e0f21a5b8cff
In some cases, the registry might be updated during a test step
(creating custom models/fields, for example). In those cases, there
should be an explicit call to `reset_changes` on the registry to make
sure that the next test class starts with a registry that is consistent
with the database state.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
When revamping the message fetching from the headless browser, since
stacktraces are available (by default) on console.error and
console.warning events I assumed it could / would be useful to show
them in the Python-level log. And they *were* quite useful during the
original fixing stage.
However they turn out not to be very useful day-to-day:
* they add a lot of noise and lead to the error message itself being
lost in a big block of red / logging.error
* when a tour fails (which is the vast majority of the failures) the
JS stacktrace always points to the same location in the tour
manager (the one which goes "this step never succeeded") which is
completely useless
* aside from being bundled, normal JS code (where the stacktrace could
be useful) doesn't generally use console.warn or console.error, it's
going to straight blow up with an exception in which case we always
get a stacktrace
Leave the stacktrace formatting for console.trace as that's pretty
much the only point of using this instead of console.log.
closesodoo/odoo#44343
X-original-commit: 34500853f39c9557852cb83cbc274f59d803922f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* remove misleading documentation about a "test failed" message, in
13.0 any uncaught exception or console.error will cause the current
test to be interpreted as failed
* fix tour manager to console.error its step and not add a second
useless error message
* fix menu tester to try and display the failure cause on failure
* improve qunit's test reporter to print the number of tests failed in
case of test suite failure
Should make test failures in tours a bit clearer.
closesodoo/odoo#44296
X-original-commit: 78121b68d099b16f2d775a7a8a963a2a0f474843
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).
Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.
That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.
Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.
Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
print that, it's formatted to show the exception type, message &
traceback
* otherwise format the garbage that is an "ExceptionDetails" object
