Odoo/odoo/modules, branch 14.0

[FIX] core: correct imports from `odoo.addons.base.maintenance.migrations`

2021-05-27T11:52:17+00:00

This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.

```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1

In [2]: import odoo.addons.base.maintenance.migrations.util as m2

In [3]: m1
Out[3]: 

In [4]: m2
Out[4]: 

In [5]: from odoo.addons.base.maintenance.migrations import util as m3

In [6]: m3
Out[6]: 

In [7]: m2 == m3
Out[7]: True

In [8]: m1 == m3
Out[8]: False

In [9]:
```

Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.

```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2

In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```

closes odoo/odoo#71323

X-original-commit: b2ea37f185bc18ecc3701a4f1f1f7a9d37a23078
Signed-off-by: Christophe Simonis 
Co-authored-by: Christophe Simonis

[FIX] modules: apply override translation option

2021-03-15T12:20:13+00:00

Translation overwriting was not working when forced by command line
arg --i18n-overwrite

This is due to the change of signature of the method, no longer
relying on the context

Fixes odoo/odoo#67419

closes odoo/odoo#67401

Signed-off-by: Martin Trigaux (mat)

[FIX] registry: prevent inherited phantom cache clears

2021-02-01T12:01:48+00:00

This patch complements the previous one by ensuring that any
`cache_invalidated=True` flag inherited from the master process
(pre-fork mode) cannot trigger a cache clear.

This could occur when the first request is served, because the flag was
never clear in the master process, which never server any request.

At the end of `check_signaling()`, the local cache has either been
cleared because a (real) increment of the cache sequence was detected,
or it is considered still valid. The final state of the
`cache_invalidated` flag should reflect this, by being `False`.

closes odoo/odoo#65303

Signed-off-by: Raphael Collet (rco)

[FIX] registry: do not signal a phantom cache clear on load

2021-02-01T11:58:25+00:00

During loading, the registry clears all `ormcache` data multiple
times, in order to ensure consistency with the newly loaded module
data.

Since 083c70bbb63f27839b2c9a4b549e216947bc4dd1, this was done by
calling `self.clear_caches()`, with the side-effect
of signalling to all other worker processes that the cache
*needs* to be invalidated, which is actually untrue.

If the other workers have any reason to reload their own registries,
they will also clear their own cache in the process - there is no
need to forcefully invalidate it globally.

One could think that combining the pre-fork mode with the `-d `
parameter would mitigate this issue, by making all workers inherit from
a fully loaded registry, In reality it doesn't work, because they also
inherit from the `cache_invalidated=True` flag, that was never cleared
in the master process. So despite having a fully loaded registry, the
newly forked workers will signal a cache invalidation upon serving
their first request.

Further, in a multi-tenant setup with large numbers of databases,
registries may be recycled and loaded much more frequently than
new workers are starting, due to the limited registry LRU, amplifying
this effect a bit.

~~

This patch directly clears the cache LRU without going through
`clear_cache()`, avoiding setting the `cache_invalidated` flag of the
registry, and thus not signalling to other workers.

This is similar to what was being done before 083c70bbb63f27839b2c9a4b549e216947bc4dd1,
where the LRU was dropped like all other lazy properties.

[FIX] core: check module state inconsistencies after `end` upgrade scripts

2021-01-07T14:30:14+00:00

Some modules may be removed by the upgrade scripts with the help of the
ORM and are done in `end` scripts.
This is the case for uninstalling the themes which use the `_theme_remove`
method [1].

[1] in 12.0: https://github.com/odoo/odoo/blob/e2084a4356f63249920d8c777e92f1710be8b5a6/addons/website_theme_install/models/ir_module_module.py#L337

closes odoo/odoo#64216

X-original-commit: e5ab5410dbc006fc4bcdd21e603026483bf5d360
Signed-off-by: Xavier Dollé (xdo) 
Signed-off-by: Christophe Simonis

[FIX] registry: transitive dependencies of custom fields may not exist

2020-11-12T11:28:03+00:00

Currently in 13.0 when creating a new model through studio and convert
the x_name field to a computed fields with a dependency set on a
custom field from a native model, user get a Key_error when upgrading
or installing a new module

due to the custom field with an invalid depends raise error through a
transitive dependency.

The loading of the registry completely fails,
because the loading of the field custom_field raises a `KeyError` exception
in `def transitive_dependencies` @ `dependencies[field]`
it happens here because the custom_field was skipped at
`dependencies[field] = set(field.resolve_depends(model))`

task - 2366502

closes odoo/odoo#61658

X-original-commit: 92f6908bae4a6678f76a3ce9e29ac3907803ceb2
Signed-off-by: Raphael Collet (rco)

[FIX] core: reinstall hooks after setting up models in registry

2020-10-27T12:42:39+00:00

Before this patch, adding a field on a custom model discards all
automated actions on that model.  The explanation is relatively simple.
When models are set up in the registry, the classes of custom models are
dropped then recreated.  Given that automated actions are implemented as
monkey-patches on model classes, the setup of models simply loses those
monkey-patches, which explains why they stop working on custom models.

The fix introduces an `_unregister_hook()` method, that is expected to
clean up what has been done in `_register_hook()`.  When the registry is
ready (i.e., not being loaded), the setup of models first invokes
`_unregister_hook()` on models, proceeds with the setup, and finally
invokes `_register_hook()` to reinstall the hooks.

OPW 2362308

closes odoo/odoo#60818

X-original-commit: ac970380deaafb8542670951ed63dc11ffaf6b6c
Signed-off-by: Raphael Collet (rco)

[IMP] core: add models defined by a query instead of a table/view

2020-08-20T07:45:18+00:00

By adding a parameter `_table_query` on the Model, we can now have views
that depend on the context.  The query is used instead of the table name
in ORM operations.  This allows to pre-compute some values to improve
performance, instead of storing context values in the database.

Co-authored-by: william-andre 
Co-authored-by: rco-odoo

[IMP] core: tests reporting

2020-08-19T14:08:21+00:00

* 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...

closes odoo/odoo#55185

Signed-off-by: Xavier Morel (xmo)

[REM] core: assertion reports

2020-08-19T14:08:12+00:00

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