From an onchange, at this point, (4) doesn't mean "no change" it means
"reset to database values". Through the interplay of client and server
reverse-engineering one another at this point the client (is supposed
to) assume the o2m results are "complete" and a diff from the
current *in-database* values rather than the in-client (sent to the
server) ones.
So a (1) should completely replace all existing values, and a (4)
should just remove all of them (but keep the record linked).
closesodoo/odoo#32617
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Technically it does 3 different things:
* switch from 1 level of o2m to 2 levels of o2m when recursing
* handles `parent.<xxx>` readonly modifiers on o2m subfields
* handles `id` readonly modifiers on o2m subfields (already worked in the
normal case but not for o2m records from default_get)
The last two especially are temporary quickfixes, that will need proper fixes.
closesodoo/odoo#32428
Signed-off-by: Christophe Simonis <chs@odoo.com>
The SSF would correctly filter out readonly fields when saving a
toplevel form, however it could not remove readonly values when saving
o2m pseudo-records to the parent form (as these would be expected to
remain available for reading upon the next edition and whatnot), so
these values would get sent in 0/1 commands.
Filter out these fields during the parent / toplevel save call.
Complexity notes:
* evaluating readonly modifiers requires the entire record, so
unchanged fields still have to be written back to the parent form
and be filtered out when *it* is set up for save, an alternative
would be to store the `changed` and `readonly` flags alongside the
record dict, and have the post-process only override the
pre-computed readonly flag using force_save
* had to fix a test to match the new behaviour, the post-edition
states turns out to be in line with the client's behaviour (or how
it looks anyway)
Fixes#32019
The extra setup probably affects any o2m whose edition view itself
contains an o2m, but most likely to blow up entirely on models with
some sort of tree structure (parent/child relationship): the SSF
eagerly loads and setups the o2m's view, and the o2m's o2m's, ... ad
infinitam.
A better / cleaner fix would be to set up the subview on-demand (and
possibly cache it), but the rest of the o2m stuff is unlikely to work
correctly recursively so just don't recurse the o2m view setup at all
for now.
fixes#31458
PRs #28645 and #31494 were not applied to 12.0, but there's no reason
not to, they should only fix things (make behaviours more in-line with
the regular client), and since o2m is an area where more fixes are
needed and it would be nice to have them in 12.0...
As a start_tour helper was added on the python side (PR #32316),
a javascript helper counterpart was needed as suggested on the PR.
closesodoo/odoo#32441
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the syntax to start a tour was extremely verbose.
With this new method, it is possible to start a tour by just giving the
essential parameter: the tour name.
The full set of features from browser_js are kept by using **kwargs.
closesodoo/odoo#32316
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When calling the initial (create / default_get) onchange, the SSF
would send the list of fields in whatever order was provided by the
fields map of fields_view_get.
The web client uses view ordering, and it turns out some uses / tests
have dependencies between onchanges (e.g. _create_payment in
test_account_reports) which break on some orderings of the fields.
Send the initial onchange using view-ordered fields in the SSF as
well.
closesodoo/odoo#31494
Actually, when running browser_js tests, the test automatically fails
when a console error is seen.
In some cases, an exception can be thrown during a tour but without
console error. In that case, another type of devtools protocol event is
fired: Runtime.exceptionThorwn. This event is not catched by the
browser_js test.
With this commit the above mentioned event is catched and the test is
directly considered as failed.
closesodoo/odoo#31555
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111f
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closesodoo/odoo#31158
* Form would entirely mis-interpret the server's response to some
results: for unmodified o2m records the server sends a (4), which was
un-interpreted by Form, leading to the o2m record being lost entirely
(as it rebuilds the entire o2m on setting)
* on record creation, every field (except id) is considered modified not
just the fields set by default_get
* Form diverged from actual client in that it would send (1, id, {}) for
unmodified o2m records, actual client sends (4, id, False)
* datetimes should be sent stringified
* onchange should not be triggered when none of the modified fields is
flagged as an onchange trigger
* the default value for numerical fields is 0 not False
* convert m2m onchange results to (6, False, ids) instead of (6, 0, ids)
for ease of diffing with actual client's data
There are still a few odd divergences in the actual invocation of
onchange when attempted on an SO, but they look to be of low relevance
/ risk.
Note: making integer fields "required" has pretty much no effect
anymore. This is in line with (my understanding of) the client's
behaviour, but required the alteration of test models as the
specific test on required... was using an integer field.
closesodoo/odoo#31064
In an HttpCase test, when the browser_js method is used, an optional
javascript code can be used to check that the page is ready to execute
the test.
When no 'ready' code is given it defaults to check the
'document.readyState' status.
In some rare cases (discovered by @Xavier-Do) this status is checked on
the 'about:blank' page. As the page seems ready, the test code is
evaluated and fails.
With this commit, when no specific ready code is provided, the test will
wait for a chrome devtools event that ensure the page is fully loaded
before starting the test.
closesodoo/odoo#30584
Before this commit, changing the value of the HOST variable didn't work because
it wasn't correctly used everywhere.
Moreover, the `web.base.url` was not correctly set: it is set during
authenticate, but when calling it from the console instead of from a request,
which is the case for tests, it is not able to grab and set the URL as needed.
PR: #30000
Odoo no longer supports python 2, thus some of these helpers can and
have been replaced by python 3 built-ins, therefore there is no need for
them to stay defined.
The removed helpers are:
* izip, imap and ifilter
* unichr, text_type
* implements_to_string, implements_iterator
* string_types, integer_types
* to_native
The python 2 shims have also been removed, and only the python 3 helpers
have been kept, because they can still be usable (i.e. accepting
both bytes and str for functions that can only accept one of the two)
[REM] pyjsparser: remove PY3 shims
They're no longer necessary as Odoo doesn't officially support python 2
anymore.
closesodoo/odoo#28519
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
When using the HttpCase browser_js method, the window size is fixed to
1366x768.
With this commit, the default window size is still '1366x768' but a test
class that inherits from HttpCase may change it to test mobile layout
by changing the browser_size class attribute.
The browser is instanciated once per test class, for that reason the
window size cannot be changed in the class methods.
To use different sizes in tests, the tests have to be splitted in
classes.
closesodoo/odoo#28760
This commit allows for not copying the currency_field attribute
of a monetary field when the monetary field is related,
and when the currency_field attribute is not explicit
Before this commit, the currency_field attribute on the related monetary
was set as the one on the distant model
After this commit, the currency_field attribute takes the field on the
current model
Though the test may appear like an incoherent use case,
it is on the contrary totally legit, as web_studio allows it
OPW 1903113
closesodoo/odoo#28144
Before this commit, the SSF would only set up edition views on o2ms at
the toplevel. This usually isn't an issue, but in some cases involing
onchanges on o2ms which themselves contain o2m, odd results could
happen as the second level would try to list the sub-o2m's fields in
order to cleanup its (possible absence of) values (cf the `subfields`
local variable in _cleanup_onchange), which would blow up due to the
missing `"edition"` key.
Fix by recursively processing o2ms and setting up their edition view.
Also fix the fields iteration in fvg processing: don't recurse inside
fields. There still is no support for embedded views (I think?) but we
should not try to treat subview fields as view fields, that could have
very bad results.
closesodoo/odoo#28645
The SSF would properly mark its own records as deleted, but it would
not properly handle deletion requests coming from an onchange, and it
would not necessarily convert DELETE_ALL commands (5) into the proper
sequence of individual (2)s matching existing records.
closesodoo/odoo#31431
It appears that chrome headless with sandboxing is failing when running
containerized because it tries to use Linux namespaces.
With this commit, the no-sanbox optional arg is used to avoid this
issue.
Closes#26456Closes#28053
The feature was not tested, and as it turns out completely broken:
* the non-raw string means the "backrefs" were really interpreted as
octal literals
* the second backref was entirely wrong
Also add all loaded views to the field descriptor in case we might
have a use for it (and because inline sub-views are always stored on
the descriptor).
closesodoo/odoo#28194
When computing coverage, the tests are slowed down and the timeout is
often exceeded.
With this commit, HttpCase headless Chrome tests timeout is increased if
coverage is detected.
When Odoo receive a SIGXCPU (CPU time limit reached), it shuts down
immediately. If a headless Chrome is running, it stays alive after the
Odoo shutdown.
With this commit, the signal is intercepeted and the Chrome browser is
properly closed before shutting down the Odoo server.
In some situations, Chrome remote debugging is sending an empty list of
opened tabs. In that case, an orphan Chrome process stays alive.
With this commit, Chrome is stopped properly in those situations.
When an HttpCase browser_js test is started, the screencast is started
and is discarded at the end of the test if no logfile was provided by
the config.
This behavior can impact the performances.
With this commit, the screencast does not start at all if not needed.
When executing a very long HttpCase browser_js test, it happens that one
of the chrome process PIPE is full (ie. clickEverywhere test).
In that case, the communication with Chrome is blocked.
With this commit the stdout and stderr of the Chrome process are
redirected to /dev/null.
Since chrome headless has been merged, js error messages are
difficult to read: some information was missing or only displayed in
full all log.
All console.error() will now be displayed in build details, and will
appear just before the python assertion.
XMO's improvement will also be used on all log: Using module and
classname of the class calling phantomJS.
Also: some small improvements on error messages to make them easier to read
Note: this commit also shown that some error were not detected:
now we will fail in any case if js log an error.
Christophe Simonis