It's not clear when and how this happened but apparently "headful"
chrome has a built-in background_page for hangouts which appears
before the `about:blank` page in the list of targets, and possibly
appears before the `about:blank` page has opened at all.
odoo/odoo#111422 was tested with chromium which apparently doesn't
have this feature either (or does it?), which probably contributes to
having no idea when it appears.
This feature also doesn't respond to `--disable-extensions`, despite
its url marking it as one:
chrome-extension://nkeimhogjdpnpccoofpliimaahmaaome/background.html
The result was that the tour runner would hook onto the hangouts
target and try to load pages, which it would reject with
`net::ERR_ABORTED`, hence the tours just getting stuck.
Fix by improving the heuristic to find a content page: look for a
target of type `page`, and with the url `about:blank`, rather than
just take whichever tab target is listed first. Requires modifying
`stop` as it can now be called after we've started the browser, but
before we've created the websocket connection.
Also move `--no-first-run` from the headless to the default switches
to avoid Chrome's migration & default browser popup, apparently it
doesn't cause Chromium grief anymore (???). If this turns out to be a
concern, add a condition on the `executable` or something.
closesodoo/odoo#122117
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Delegate the property's resolution to a top-level function,
cached (with a single slot). This is slightly less efficient than
using some sort of global set once, but it's much easier.
Unlikely to be a huge issue in the face of *starting an entire
browser*, but may as well skip it.
closesodoo/odoo#111422
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It doesn't need to store so much crap as attributes, and the data flow
of the init can be made more explicit.
- have setup functions return stuff, which can be set on `self` by the
`__init__`, making the dataflow more explicit
- maintain a high-level `Popen` object instead of moving a `pid` around
- pass items like browser size as parameters instead of attributes
- remove redundant attributes like `screencasts_frame_dir` (/ convert
to properties)
Part-of: odoo/odoo#111422
Chrome's screencast / remote view (in the remote devtools) is
apparently *designed* for touch emulation /
simulation (https://crbug.com/1410433), which is not convenient when
trying to debug mouse-bound issues in a tour (e.g. drag&drop
problems).
However we can "simply" run the thing in a normal browser, on a watch
basis, and shut down the entire thing after each tour-call. This also
obviates the need for complicated cleanup steps to try and isolate
tours (as we can just delete the profile the browser created),
although it is somewhat less efficient as we keep starting and
stopping the browser.
It does simplify the result of merging `clear` and `stop` (into stop).
The switches setup does have a few foibles:
- `--no-first-run` causes tours to not run at all on my machine, in a
non-headless browser, so it's left just for headless
- also moved a bunch of other flags which seem to be mostly for
automated annoyances to headless only
- left extensions for now, not entirely sure which is the right one,
since we're running with fresh profiles I would assume there's no
extensions anyway
Part-of: odoo/odoo#111422
When inside an HttpCase, the end of a successful request will
`signal_changes` meaning that the registry_invalidated flag is removed.
A second issue is that this flag is thread local meaning that if a
request set the flag, it won't be visible from the test thread.
For those reasons, this commit ensures the registry sequences are
incremented as in production mode, and adds a check that the sequence
didn't change during the tests, calling `setup_models` the registry
manually if needed.
closesodoo/odoo#121268
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.
Bonus point: tests no longer need to be imported in the `__init__.py`
file.
closesodoo/odoo#121453
X-original-commit: ed1b27dbdfc0a5084051c59da9c4578262b3bf8c
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>
Before this commit, the date/datetime/daterange fields only allowed for
an optional end date field. This meant that the primary date was always
the start date.
This commit allows the field to do the opposite: with the primary date
being the end date, and having a `start_date_field` option for an
optional start date.
closesodoo/odoo#120695
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
- process modules to uninstall individually in order to better handle
their state at that point
- uninstall (and reinstall) modules in provided order, rather than
whatever postgres feels like (or a sort which might not match what
we want), mostly useful when uninstalling modules in bulk
- warn if a module is either missing or already uninstalled, rather
than silently do nothing
closesodoo/odoo#120261
X-original-commit: 034b317a908d1aea6dc6d992c489b30ffff8f1ce
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- switch to `dictConfig` for easier bulk-manipulation of loggers
- set `unlink` and `ir_model` loggers to warning, to limit the
humongous spam that is a normal uninstall session
X-original-commit: bee7898a5af68128b599d30ac7d4c0193e765afd
Part-of: odoo/odoo#120261
Add subcommands to make running the script clearer (as exclusive
switches is a bit weird nowadays).
Keep the old `--uninstall` and `--standalone` switches, but make them
mutually exclusive (and optional) to retain current behaviour.
X-original-commit: 933841eda86292f180170b32da621f55fe6f0b84
Part-of: odoo/odoo#120261
- ensure `test_module_operations` exits with a non-zero status on
failure, as the current makes it a lot less convenient to notice
uninstall / reinstall errors (especially with lots of warnings
crowding the logs)
- allow uninstalling without reinstalling, so it's easier to inspect
db state after uninstall
X-original-commit: 712977faf9bf98d9087368ab4fe95f089a072601
Part-of: odoo/odoo#120261
This commit allows the server-side form arch parser used in tests to
also include the "end_date_field" defined in the `options` attribute of
daterange widgets in the dictionnary of fields found in the arch.
The daterange widget is currently the only case where the client adds
another editable field dynamically in the list of known fields. This is
not ideal since the server does not know that when computing the initial
arch sent to the client. The workaround is to also include the
"end_date_field" in the arch with `invisible="1"`, and to add a special
case for the server-side form arch parser used in tests.
Ideally we would want a proper way to define field dependencies in the
arch, but since this widget here is the only use case for that feature
it is better for now to handle it in this simple, more naive way.
Part of task 3121497
closesodoo/odoo#112171
Related: odoo/enterprise#38569
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Making a test post_install using @tagged should always remove the
at_install tag.
The main reason for that is that runbot split config select if an
at_install or post_install tests should be executed is using negation:
`--test-tags -post_install`. The reason for that is that giving a positive tag will
replace the "standard" tag and non standard tag could be executed if
giving `--test-tags at_install` (without negation)
Since runbot tests in parallel builds, one of them using
`--test-tags -post_install` and the other `--test-tags -at_install`,
a test that is both post install and at install wont be executed at all.
Also, a tests with both tags will be executed twice
in a normal flow, usually not intended.
The correct way to make a test post_install is to use
@tagged('post_install', '-at_install')
closesodoo/odoo#118969
X-original-commit: d1db306b212d4abb5b2faab9e56c8e83b85c53b9
Related: odoo/enterprise#39966
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Precommit hooks would stock data until a call to ``cr.flush`` was made.
Notably, this happens when the ``assertRaises`` method is called.
Functions were applied on records already cleared from the cache.
This change adds a cleanup call for `TransactionCase` as it keeps
the same cursor for all tests. Cursor precommits can now
be safely executed inside tests.
Task-2834304
Forward port of #117555closesodoo/odoo#118290
X-original-commit: ff5d0c75fcea5842c5236b1b3f7480ef5a3dc415
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
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
Xavier Morel