This is related to
826c86e9ab31963e410887a30326f45bcfadf5ea
The case is the same,
a custom field with an invalid depends,
except that this time its through a transitive dependency.
e.g.
custom_field_2 depends on custom_field_1
custom_field_1 depends on unexisting_field
The loading of the registry completely fails,
because the loading of the field `custom_field_2` raises a
`KeyError` exception in
`def transitive_dependencies` @ `dependencies[field]`
because the `custom_field_1` was skipped @ line
`dependencies[field] = set(field.resolve_depends(model))`
Landing in a state where the server can no longer start at all,
and the user can't therefore solve its custom field himself
to repair the situation.
closesodoo/odoo#51057
X-original-commit: 7b642884cc4d643a5a998b4639bf26b4e81cc46e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Use `warnings.warn` to log a warning entry on usage of deprecated
import hook instead of `logging.warning`. The `warnings` can be more
easily configured to show/hide class of warnings or to limit warning
emission, plus it is possible to log a single stack entry whereas
logging can just log the entire call stack.
Bring back the various openerp import hooks by reverting 9e1f13bac12
closesodoo/odoo#50604
Task: 2234749
X-original-commit: 5840202802c2ff6ca1ca8fd6f3892900481db5da
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
Iteration methods on LRU were removed because they were not
thread-safe and it's not clear that making them thread-safe is the
correct thing to do, so not providing them seems saner.
I thought I'd looked for usages of the LRU but apparently didn't look
hard enough as I missed that it's used by the cron workers (apparently
using the threaded server we only run crons for dbs currently living
in the registry cache, the more you know).
Convert these to iterating on the LRU's internal mapping, and also
don't iterate on the LRU to clear its entries one by one when we can
just clear the entire thing safely, although Registry.delete_all
really seems completely unused.
closesodoo/odoo#49023
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This greatly reduces the number of queries to add foreign keys (notably
for many2one fields).
This saves 6.5% of the total installation time.
X-original-commit: 13a2666b4da09fc0ec7608a974dadde45f76fd7a
Reduce the number of queries to create and drop indexes.
This saves 1.5% of the total installation time.
X-original-commit: 0e1e480da9d971575feba64038c4fa518ebe102b
When installing a database from scratch, marking all packages (in the
module graph) as 'update' forces the migration manager to retrieve all
migrations scripts... for nothing.
X-original-commit: fd8f3c73c8c30162034c7712fa0993e2408fba89
This is necessary in order to create models on-the-fly within tests and
to test improper Model / Field creation: registry.reset_changes will
only perform the reset of the registry if it is invalidated, however if
the setup of models crashes before it is invalidated (as is the case of
a test), the reset_changes will not be triggered and thus the registry
will be left dirty for subsequent tests.
* from collections import <ABC> is deprecated, unclear why the
deprecation warning didn't appear before (possibly only appears in
3.7/3.8?) either way `collections.abc` should be 3.3+ so switch
everything to it.
* add some more ignores on third-party packages deprecation
warnings (meh)
* while at it, mitigate generation of non-breaking space on some
versions of Babel (in the french locale used by our tests anyway)
closesodoo/odoo#47581
Related: odoo/enterprise#9214
Signed-off-by: Xavier Morel (xmo) <xmo@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>
Before this commit:
- Install a module
- Uninstall the previously installed module
- The registry will complain that some dependencies may be missing
for the module being uninstalled
This happens because we check after the installation / upgrade of
modules that none have been left in a transient state to verify that new
dependencies have been properly installed and loaded, this applies to
'to install' and 'to upgrade' states however it's not the same for 'to
remove' states, as the process of uninstall happens much later in the
code.
After this commit, simply uninstalling modules will not trigger this
error log.
Do note that in case of a problem with an uninstall, the function
"reset_module_states" will tackle the case of leftover transient states.
closesodoo/odoo#47495
X-original-commit: c095a28314f78d1d9854e5e9bcb26014922a4f12
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this the `--unaccent` flag does double duty to specify whether
to create new databases with the extension *and* to try to use the
corresponding function.
The latter is further gated on the function existing at all in the
database.
Given postgresql does not have unaccent installed by default it seems
only the latter is really useful and we can ignore the flag to decide
whether to enable unaccent features, if the extension is installed
consider that it should be enabled and move on.
Merge this in master rather than previous versions as it can change
things like index access / use.
closesodoo/odoo#47377
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A future upgrades improvement will be to add tests in upgrades
modules. This small imp will scan in upgrade for some tests,
specific tooling will be added to upgrade repository in odoo/upgrade#878closesodoo/odoo#47030
X-original-commit: 59b5a03bdf7ae1ad8851a67d278edc31a26a96a8
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Some of the implicit side-effects got missed, namely that under some conditions
(e.g. using an odoo subcommand) `initialize_sys_path` can be called before the
config has been loaded at all, resulting in the first call not properly setting
up things, and one of the subsequent calls fixing things up.
Since this breaks workflows right now, quickly fix it, we'll re-investigate
how to fixup the entire thing in order to restrict & enforce a single call.
closesodoo/odoo#45844
X-original-commit: 6cb4c829e1559bcf836e4b573051760565b7d0c1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
On a standard odoo install, `MigrationManager._get_files` represent
more than 4% of an install. This is because the legacy
odoo/base/maintenance/migration path was added to upgrade.__path__
once by module, making the get_filed check 574^2 os.path.exists.
This commit adds a check on initialize_sys_path to call it only once,
and merge legacy path with upgrade-path management in order to benefit
of the `up not in upgrade.__path__` check. This second part of the fix
will also remove the local dir from the upgrades paths.
A further improvement would be to fix MigrationManager in order to skip
_get_file work on a fresh install, (wip by rco-odoo)
closesodoo/odoo#45699
X-original-commit: 497330a695ed52a33f9c9b9c27b149446de0db29
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Sometimes, constraints are not delayed during a module upgrade: the
module is 'to upgrade' but in 'init' mode :-/
Fix this by relying on the module's state only.
closesodoo/odoo#45179
X-original-commit: 878b6538961a9b6a5fe1c6ac68d4ff39391abcdf
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In some case, a pre-migration script calls `xml_import.parse` to force
reload a no-update data in pre-script. It is possible that fields are
marked to recompute in the process. The problem is that the reference to
the field added in `env.all.tocompute` won't be the same as the
reference of the same field after calling `registry.setup_models()`,
leading to an infinite loop while recomputing this field, since
`fields.__get__` wont find `self` in `env.all.tocompute`.
This problem was discovered when trying to migrate a database with all
modules installed (no demo data) from 12.0 to 13.0 (for commit
references: http://runbot.odoo.com/runbot/build/1176576 with database
comming from http://runbot.odoo.com/runbot/build/1171714).
This commit adds a check before executing `registry.setup_models()` in
order to log when some fields to compute remain before breaking fields
references, and adds a `flush()` after pre-scripts to fix the current
issue.
X-original-commit: 41b9d810066774736c4077bba1dc9c9fba004f48
When adding a custom field, the ORM also adds it to all the inherits'ed
models, but with the state `base`, because those inherited fields are
automatic (created by the ORM). However, dependencies are enforced for
`base` fields, while they can be ignored for `manual` ones. This is a
problem when a custom field is fucked up: its inherited fields will make
the registry crash.
We fix the issue by not enforcing dependency check on fields inherits'ed
from custom fields.
opw-2191114
closesodoo/odoo#45024
X-original-commit: 2db0787dc9e8717200aaf1d71ac64df1c17f4143
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit models with the `_transient` flag were ignored in
ir.model.access verifications. Only an implicit ir.rule with the
domain (create_uid=user.id) was applied to avoid most side effects.
The problem is that, often, the security does not lie in side-effects
of abusing of somebody else's wizard record but in the fact that the
wizard methods blindly trust only the right users are creating these
records. Too often, too many sudo were used and creating wizard with
chosen values could lead to an abuse scenario.
Instead, explicitly require the developer to declare security rules
the same way as on any other model.
Since this option is soon to be used, this rename is a last tweek
to make it more logical to use since it will point to a single
upgrade dir most of the time.
closesodoo/odoo#44593
X-original-commit: 1c8e2809fb296abce6114b7da906d48a240df418
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When removing a custom model, it remained listed in the base classes
(normally `base` and also possibly a list of mixins; e.g. `mail.thread`
or `mail.activity.mixin`) list of inheriting classes, possibly causing a
crash when trying to reload the registry.
This commit ensures that any custom model is removed from its parent
class `_inherit_children` set; it will be re-added automatically during
the call to `_build_model` if the custom model still exists.
Co-Authored-By: Raphaël Collet <rco@odoo.com>
Migration have long been only accessible thanks to a symlink from
`odoo.base.maintenance` to our private migration repository. Thank to
the change of bbb1a8f it is now possible to give a load the
migrations scripts from a path given in options.
The `initialize_sys_path` function has been updated to hooks the new
paths or the legacy symlink and to provide aliases to the previous
import logic to ensure backward compatibility.
`odoo.upgrades` (`community/odoo/upgrades`) is a new namespace that hook
all `--upgrades-paths` directories or the
`community/odoo/base/maintenance/migrations` symlink if none is previded.
`odoo.addons.base.maintenance.migrations` has been made an alias to
`odoo.upgrades`.
The `odoo.upgrades` is the desired method for accessing migrations
scripts and should be used by all new scripts.
closesodoo/odoo#44117
Task: 2178274
X-original-commit: d963cc05acd882729c4eb5ab940dae2a2197e55a
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Studio customization is an exception, a data module added to ir_module
but that is never added to graph since there is no manifest.
OPW #2180885closes#43880closesodoo/odoo#43940
X-original-commit: 4051ac83b5e7cc1cb91a264b51401ad5601ad4e2
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When migrating a database, load_marked_modules will be called multiple times, alternating
to upgrade and to install modules. The main reason for this is still a litle confusing
but it as the side effect to log "Unmet dependencies" error multiple time in add_modules,
even if the dependency will be resolved later.
This commit removes the error level for this log, and replace it by another check,
performed at the end, logging any module in "to install"/"to upgrade" state.
Also log removed module as info (25), not warning. This may be changed latter
closesodoo/odoo#43797
X-original-commit: c5d6a3977de85fb974a4940fb11d54ef847e08e4
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When a call to init_models() fails, the post-init queue still contains
callables that refer to a soon-to-be-closed cursor. If one calls
init_models() in another request, the post-init process will inevitably
fail because it refers to closed cursors.
closesodoo/odoo#40379
X-original-commit: 33f87ffebaa1cb38e3ce8ce44c8b8b538b49e5b9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Ignore exceptions when resolving dependencies in that case.
This reimplements a behavior from former versions.
closesodoo/odoo#40300
X-original-commit: 826c86e9ab31963e410887a30326f45bcfadf5ea
Signed-off-by: Christophe Simonis <chs@odoo.com>
This commit partially backports bpo-24412, which allows the definition of
class cleanups (addClassCleanup) and module cleanups (omitted),
similar to instance cleanups (addCleanup).
This is useful for tests that override unittest's setUpClass and
could crash during its execution: If this happens, it is possible that a
bunch of crap is left in the database or even worse, the cursor becomes
completely fucked; Thanks to the addClassCleanup, we can undo the damage
done by the setUpClass.
Another benefit is that it is called unconditionally after tearDownClass
is called, so it can also be called as a replacement and/or safer
tearDownClass.
The queries made by the method `_is_an_ordinary_table` represent about
8% of the time to do a full Odoo installation. Use a cached query for
all tables on the registry to reduce that time to some negligible
amount.
closesodoo/odoo#39262
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`openerp` module/addons imports has been deprecated in v13 by 7c47eb1
for removal in v14.
If you were still using the removed aliases, please substitute all
`import openerp` by `import odoo` and `import openerp.addons` by
`import odoo.addons`.
If you were still using the removed `ad_paths` proxy, please use the
python standard `odoo.addons.__path__`.
closesodoo/odoo#37007
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
[PEP-594] is deprecating the `imp` module, that module is used in
`module.py` in order to dynamically import addons using any of the
`odoo.addons` or `openerp.addons` import anchor.
We are deprecating `openerp` module/addons imports in v13 in order to
remove the support in v14 and greatly simplify how modules/addons are
loaded. If you are still using the old `import openerp` or `import
openerp.addons`, `import odoo` and `import odoo.addons` are drop-in
replacements.
The `odoo.modules.module.ad_paths` addon paths list has been deprecated
too. The list is now accessible on `odoo.addons.__path__` where they
are now directly loaded [2].
See also:
[PEP-594]: https://python.org/dev/peps/pep-0594/
[2]: https://packaging.python.org/guides/packaging-namespace-packages/closesodoo/odoo#36597
Task: 2003936
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This prevents a bunch of queries that are useless when creating a
record. Indeed, right after a record has been created, no other record
has a many2one reference to it. In other words, inversing a many2one
field from the record just created always gives an empty recordset.
Those useless inversions generate about a dozen queries when creating a
`res.partner`, for instance.
This saves queries, but not much time.
closesodoo/odoo#36566
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit --log-level had no impact on test logs.
We need to check logger "isEnabledFor" before makeRecord
since logger will make this check in error,warn,log...
dedicated function before making call to _log.
We also need to use modules.py runner instead of unittest
logger in OdooTestRunner (test will allways be a suite there)
closesodoo/odoo#36142
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Since 735ee54 the logs are improved by getting additional informations
from the traceback. When the test fails during the setUpClass, the test
object received by the getCallerInfo method is not a TestCase instance
but an _ErrorHolder. Although they should have the same API, as stated in
unittest documentation, the _ErrorHolder does not have a
_testMethodName attribute leading to a warning.
With this commit, the warning is skipped in that particular case.
closesodoo/odoo#36108
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
This commit adds a new way to use upgrades scripts folders
whithout needing to symlink them to an hardcoded path.
The folders specified in --upgrades-paths is then being used by
migration.py to find and execute migrations scripts per module
specified in the -u CLI option.
The folder needs to have the following structure:
- <upgrades_paths folder 1>
- <module1 name>
- <version1>
- <script1>
- <script2>
- ...
- <scriptn>
- <version2>
- <scripts>
- <module2 name>
- <versions>
- <scripts>
- ...
- <upgrades_paths folder 2>
- ...
Update odoo/tools/config.py
Co-Authored-By: Olivier Dony <odony@users.noreply.github.com>
Christophe Simonis