| Age | Commit message (Collapse) | Author |
|---|
|
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]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
In [5]: from odoo.addons.base.maintenance.migrations import util as m3
In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>
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 <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
|
|
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) <mat@odoo.com>
|
|
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) <rco@openerp.com>
|
|
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 <db>`
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.
|
|
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) <xdo@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
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) <rco@openerp.com>
|
|
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) <rco@openerp.com>
|
|
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 <wan@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
|
|
* 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) <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
|
|
Attempts to clean up odoo/module and odoo/service a tad, they still
invoke testing-related utilities but are more logical in what
they *contain*.
|
|
The `PackageLoader` jinja's loader purpose is to discover template files
given a python module path. It was necessary to register a special hook
into the import scheme of Odoo to support `import crm`, `import openerp`
and `import openerp.addons` like module path.
Since the support for those old module paths is deprecated since v13 and
the jinja's team shows desire to remove support to `pkg_resource` utils
as highlighted by #50552, it is better to remove it.
closes odoo/odoo#53515
Task: 2282681
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Before this, invalidations to the UID cache is not synchronised
between workers because it's an ad-hoc solution (so a user changing
their password or an admin disabling a user would only lock out an
attacker currently using the API of one of possibly several
workers). Shift the entire thing to ormcache which already has proper
support for synchronising cache invalidation between workers.
Also simplify the cache invalidation mess in Users.write because the
caches have been unified into a single registry-level LRU, so the
half-dozen cache clears on specific ormcached methods & models is
pretty much the same as repeatedly calling clear_caches on the current
model.
**However** registry.cache is trivially accessible from server actions
and safe_eval as long as they provide access to a model (through
`model.pool.cache`). Which is common, and an issue given we're very
much putting sensible data in there.
Fix this by renaming `Registry.cache` to `Registry.__cache`, this
requires few editions and mangled names are not accessible from
safe_eval contexts.
The alternative would have been to add more bespoke handling of the
uid cache to hook it into the cache invalidation propagation
machinery.
After discussion with (@)odony, fixing LRU access and using that seems
cleaner and less error-prone.
Note on lazy_property
=====================
Make Registry.cache / Registry.__cache into a regular attribute: the
overhead of the LRU is not that high (compared to that of the registry
itself), it's rare that we *don't* need it, and it's assumed to be a
persisted attribute (it's not just a cache) so making it a normal
attribute seems fine; and lazy_property doesn't work for mangled
names: the name of the property is mangled using the name of the
definition class, but the name of the symbol (fget) is not mangled so
lazy_property would set the __cache attribute but then Python would
lookup _Registry__cache, creating a new cache every access.
And we can't (always) mangle things correctly on `__get__(obj,
owner)`: `owner` is just `type(obj)`, meaning in the case of
inheritance the type we get is the type through which the property is
accessed rather than the one it's defined on. So it would work in the
cases where no inheritance is involved (such as Registry.__cache) but
not in general (lest we want to play around walking the MRO ourselves
to find the definition source, which doesn't seem worth it).
lazy_property *could* be made to work properly on Python 3.6+: the
descriptor protocol gains `__set_name__(name, owner)`, which is called
with the properly mangled name — and with the definition class to boot
(though there might still be issues when overriding lazy properties as
the override will be mangled & named differently... or maybe that's a
feature?). However we're still supporting 3.5 at this point, AFAIK, so
that's not an option. Plus it feels unnecessary / not very useful.
However add an assertion to `lazy_property` so it signals when we try
to use it on a mangled method (as otherwise it kinda sorta work in the
sense that the property / object is accessible but is in effect a
slower way to write a regular property).
|
|
This is a followup of commit bc2bb5e03c2b32d4ee1b0597ea5889c17d2b0e0e
When a module is updated, a constraint application may (temporarily)
fail because the existing data does not respect the constraint, this is
OK and can be fixed through hooks/migration scripts and was handled by
the aforementioned commit.
However when updating multiple modules, it is possible that an
inheriting module will try to re-apply the failed constraint and
succeed, if that is the case, when processing the `post_constraints` an
already-existing constraint will be applied and raise an error.
To fix this, a check is made before trying to apply the constraint, to
verify that it is not already in _constraint_queue, if it is not, then
we may attempt to apply it, if it is in the queue, then we may safely
ignore it as it will be applied further down the registry cycle.
closes odoo/odoo#55725
X-original-commit: 5225b9ce5178302af05b63029fb184e27b781815
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
|
|
Currently there are a few issues with testing reporting (at the
command-line):
1. there is a global report after at_install tests, but it gets
"scrolled off" by long post_install tests, and is thus easy to
miss
2. with test tags, it's easy to fat finger a typo and run 0 tests,
which look like everything's running fine (no failure)
To improve this, print a global report at shutdown (in
`--stop-after-init` mode if tests are enabled) which recapitulates the
test results *and prints a warning if no tests were run at all*.
Also update the reporting collection to make this more reliable:
* have `run_unit_tests` return `None` if it has run no tests, the
assertion reporting machinery counts this as neither success nor
failure which is exactly what we want
* have load_test only report a success *if files were actually
loaded* (by having `load_data` return that information)
Task 2301268
closes odoo/odoo#54812
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
The `initialize_sys_path` is the function responsible of getting the
custom Odoo import hooks to work, i.e. addons import via
`import odoo.addons`. This function is called by some other module
related functions to ensure the paths are correctly setup. We are
confident it is useless to re-initialize the path in many places.
The `load_openerp_module` function is called during server bootup by
both `odoo-bin server` and `odoo-bin shell`, both command parse the
configuration before starting the server which initialize the paths
already.
Most call to `get_module`, `get_module_path` and `get_resource_path` are
done in models or controllers where a registry is setup already. There
is one notable exception which is the subcommand discovery done during
the bootup, for that specific case, we initialize the paths with a
partially loaded configuration.
closes odoo/odoo#49715
Task: 2200956
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Debugging/improvement of an at install test may be tedious because of
the need to update the module, spending most of the time checking
tables and xml file.
1. This commit proposes to allow to execute test without installing or
updating a module. The test is still executed during the loading, and
the behavior should be close to an execution of tests during an update.
Co-authored-by rco-odoo <rco@odoo.com>
2. keep previous behavior if -i or -u is given
Three solutions were possible:
- The clean one that changes dev habits.
When test-enable or test_tags is given, all tests are always executed,
a test_tags is needed to select tests to execute:
Example: `-u module --test_enable` becomes `-u module --test-tags /module` to keep the same behaviour
This solution is the simplest, and executed tests does not depends on database already installed modules.
- The conservative solution.
When giving -i or -u, the behavior stays the same as before. When giving test-enable
without -i/-u, test are executed on all installed modules.
- The intermediate solution:
When no test_tags is given but a -i and -u is given, only the given modules are tested.
This is quite close to the second solution except that a -i module on a new database won't
test all dependencies on the first install.
The chosen solution is the second one to minimize changes on dev old habits,
only an almost unused feature is impacted: using test-enable without any -i or -u.
Before this pr only post install tests were executed in this case. Now at_install tests are also executed.
This combination is actually used by runbot to execute post_install test in parallel, but a `--test-tags -at_install`
tag is given so nothing to worry about here.
closes odoo/odoo#53499
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Every call of initialize_sys_path was adding two new hooks to the
sys.meta_path, resulting in very long loading times on databases having
a lot of modules.
For example, 2.27s instead of 752 on a database having 130 installed
modules.
References:
- odoo/odoo#45780
- odoo/odoo#45662
closes odoo/odoo#53121
X-original-commit: 2444fde7f852787d87589a93c4bc385d76ff20e9
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
|
|
Oversight of "simple refactoring" in 634775bff6d9eba9d4548cc801071a942895a719
closes odoo/odoo#51158
X-original-commit: 046b0dedda8f43e4ae13958a34a446e8a73c8d3f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
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.
closes odoo/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
closes odoo/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.
closes odoo/odoo#49023
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
This saves 1.5% of the total installation time.
X-original-commit: afd39e1a9824252d13823e484c60ad813b9b51a6
|
|
This saves 4.5% of the total installation time.
X-original-commit: 8519064dce975af542ccd30dc14c56b9bb36d07b
|
|
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
|
|
This is a simple refactoring.
X-original-commit: 634775bff6d9eba9d4548cc801071a942895a719
|
|
This saves 2% of the total installation time.
X-original-commit: 6a0028f91944b1d9e4eac026e86ca249ef5bc7ee
|
|
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)
closes odoo/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.
closes odoo/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.
closes odoo/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.
closes odoo/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#878
closes odoo/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.
closes odoo/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)
closes odoo/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.
closes odoo/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
closes odoo/odoo#45024
X-original-commit: 2db0787dc9e8717200aaf1d71ac64df1c17f4143
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
closes odoo/odoo#44800
Co-authored-with: Xavier Dollé <xdo@odoo.com>
X-original-commit: bc2bb5e03c2b32d4ee1b0597ea5889c17d2b0e0e
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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.
|
|
Was already not used, it's just that the import was not
removed. Remove a bunch of other unused imports while at it.
|
|
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.
closes odoo/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.
closes odoo/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 #2180885
closes #43880
closes odoo/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
closes odoo/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.
closes odoo/odoo#40379
X-original-commit: 33f87ffebaa1cb38e3ce8ce44c8b8b538b49e5b9
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
