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>
An unintended side-effect of #29431 is apparently that auto_install
applications automatically get reinstalled when uninstalled, which was
not the goal.
Move the auto_install selection back into db.py, this version seems to
work even though the previous attempt was apparently unsuccessful.
closesodoo/odoo#35180
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
A special folder named `0.0.0` can contain scripts that are run on
upgrade of any version.
They are useful to make some sanity checks or other verifications to
ensure database consistency.
The first version of this patch used the more eye-catching `any` for
the migration folder, but it was problematic for upgrading from an older
version that doesn't contain this patch.
Using a version "number" containing two dots is required to avoid it
being prefixed with the server version (see `convert_version` method) and
resulting in a version like `10.0.any`.
Such version would have been executed, even without this patch, when
upgrading from an older major server version (9.0.1.0 < 10.0.any).
closesodoo/odoo#34268
Signed-off-by: Christophe Simonis <chs@odoo.com>
Traceback coming from tests are currently logged
line by line. This will implies that runbot will have one
ir_logging entry per line which is not practical. More than
that, the log prefix can make the traceback less readable
because of line returns and difficult to copy paste.
This commit simply remove this feature. After discussion with odo
and chs, we will also remove the docstring from test shortDescription
since most of the time this information is not clear and can be accessed
in source code if needed.
closesodoo/odoo#33911
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Since #34996, in some case, the error detail was not logged keeping
only the final summary "x errors, x failures" when running TestSuite.
Making fail test test_cache_invalidation for instance won't show
a detailed message when breaking test_01_project_tour will.
This issue occurs when using subtest, like with assertQueryCount,
@users decorator, test_all_l10n, and test_youtube_urls.
Since Testresult addSubTest append directly to error and failures
instead of calling addError and addFailure, we need to ovewrite
addSubtest too.
closesodoo/odoo#35270
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
1. Make test logs clearer & remove redundancies
Instead of having an ERROR log right when the test fails then print
the useful / relevant information at the end of the test suite,
immediately print the traceback. Keep the final summary. Also avoids
having to wait for the entire test suite to end before a dev' can know
the failure details of a specific test.
Done by working at a lower level and replacing the custom
test stream mess by a custom Result class which prints and formats the
information we want. Replace TextTestRunner by a bare-bones custom
Runner object to tie it in.
2. Provide useful location information on test failure
Leverage the work above to log the test function's failure location:
previously logging would point to within TestStream which is not
useful.
Here, on failure the traceback is used to discover the caller info and
point to the test line which fails instead. similar to unittest's
_exc_info_to_string (https://github.com/python/cpython/blob/93e8aa62cfd0a61efed4a61a2ffc2283ae986ef2/Lib/unittest/result.py#L173).
3. Replace direct logging in browser_js by raising errors
Properly marks the test as in error, and the error traceback points to
the tour definition / launcher (python side) rather than common.py
and/or module.py.
Also removes unused dbname parameter that was added in
/278ed718e9805edf088642ba10d3b7c4e5716c31/openerp/modules/module.py#L361
for nor visible reason
closesodoo/odoo#34996
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Store the SQL constraint message directly in the field `message` of the
corresponding `ir.model.constraint` record, and manage translations from
there. Those records are given an XML id in order to be tracked in PO
files. The translation type 'sql_constraint` is removed.
Context:
After a module update, the records present in ir_model_data table but not in
self.pool.loaded_xmlids are considered as no longer needed and should be
removed.
An exception is done with noupdate=true entries.
Bug 1:
Entries with noupdate=NULL are not considered in the evaluation and are ignored
while it may be worth deleting.
Bug 2:
Some records with their external id being automatically created are not present
in self.pool.loaded_xmlids and may get removed after updating a module.
By a lucky coincidence, bug 1 make it so that records targeted by bug 2 are
ignored and not deleted (the "automagically" created ir.model.data often lack
a noupdate value).
Fix Bug 1:
Use a COALESCE to find both records with noupdate=NULL and noupdate=false
Fix Bug 2:
Depends on the source of the generated external id:
- ir.model:
The entries created through _reflect_model were not loaded in
self.loaded_xmlids
Use the proper ORM method _update_xmlids that correctly populates
self.pool.loaded_xmlids
- ir.model.category:
The categories were generated when the db was initalised, doing SQL was not
avoidable.
Create the categories in noupdate to avoid it being considered for removal.
- ir.property:
Are always created in noupdate in data files but in stock_account it was
manually created without being in noupdate
closesodoo/odoo#32881
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
As most of the tests are using demo data, a check is performed to verify
that they are loaded.
A best practice is to write tests that does not depend on demo data but
with this check, it's not possible to launch them without demo data.
With this commit, the check is removed, allowing to launch test even
without demo data loaded.
closesodoo/odoo#33531
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Currently, auto_install is triggered when all dependencies get
installed, but there are cases where one would want such trigger on
only a subset thereof.
e.g. we want `website_sale_dashboard` to auto-install when
`website_sale` is installed. Currently, it requires `web_dashboard` to
also be auto-installed otherwise `website_sale_dashboard` would "wait"
for both dependencies to be explicitly installed before the
auto-install triggers. That's despite `web_dashboard` not being very
useful on its own. More generally this is an issue with technical
modules which need to be marked as auto_install so as not to block
e.g. bridge modules from automatically installing.
This change allows setting `auto_install` to a subset of `depends`:
* if auto_install is set to `False`, the module does not get
automatically installed (no change in semantics)
* if auto_install is set to `True`, the module gets automatically
installed if and only if all its dependencies are installed (also no
change in semantics)
* if auto_install is set to a list of dependencies, the module will be
installed when all *these* dependencies are installed, other
dependencies (excluded from auto_install) will be installed
alongside as a consequence
* auto_install can be set to an empty list, in this case the module
will always be automatically installed regardless of its
dependencies (and will force their installation).
So after this change, `web_dashboard`'s auto_install can be set to
`False` (such that it's not installed if no module defining dashboards
is installed) and `website_sale_dashboard`'s manifest can be edited
to:
'auto_install': ['website_sale']
possibilities:
# no automatic installation
'depends': ['a', 'b'],
'auto_install': False
# automatic installation if both a and b are installed
'depends': ['a', 'b'],
'auto_install': True
# automatic installation if both a and b are installed (explicit)
'depends': ['a', 'b'],
'auto_install': ['a', 'b']
# automatic installation if b is installed, a will get forcefully
# installed if it isn't yet
'depends': ['a', 'b'],
'auto_install': ['b']
# always automatically installed, will cause the installation of
# its dependencies even if they're not marked explicitly
'depends': ['a', 'b'],
'auto_install': []
Task 1851328
closesodoo/odoo#29431
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This reverts commit 5f4a945182.
The cure is worse than the original disease.
The main installation cursor often holds exclusive locks (due to DDL
changes) on vital tables such as res_users. As a result, using
another cursor to perform changes while the main cursor is waiting
is extremely deadlock-prone. And these deadlocks can't be detected by
PostgreSQL as they mix Python-SQL locking, which leads to deadlocked
HTTP workers.
Related to:
- opw-1916918
- #29528
- Create a new DB with `base_automation`, without demo data
- Switch to developer mode
- Go to Settings, then 'Load demo data', validate
A traceback occurs.
An error since the demo data in `base_automation_demo.xml` are pointing
to `model_base_automation_lead_test`, which is a test model. It is
therefore not created whithout demo data. The error is:
```
bad query: b'RELEASE SAVEPOINT "5159....."'
```
However, that's not the real crash. Indeed, in case the installation of
demo data crashes, `demo_failure_todo` is supposed to handle the
situation like a boss. But in this case, the DB cursor seems unusable.
Therefore, the following crashes like a gros caca:
``` python
todo = env.ref('base.demo_failure_todo', raise_if_not_found=False)
```
Solution: use a new cursor.
opw-1916918
closesodoo/odoo#29528
This allows a model to have several fields using the same relation on purpose,
for instance to show the related items filtered by domains.
Also adapt the code to handle multiple many2many inverses.
closesodoo/odoo#30338
Odoo no longer supports python 2, thus some of these helpers can and
have been replaced by python 3 built-ins, therefore there is no need for
them to stay defined.
The removed helpers are:
* izip, imap and ifilter
* unichr, text_type
* implements_to_string, implements_iterator
* string_types, integer_types
* to_native
The python 2 shims have also been removed, and only the python 3 helpers
have been kept, because they can still be usable (i.e. accepting
both bytes and str for functions that can only accept one of the two)
[REM] pyjsparser: remove PY3 shims
They're no longer necessary as Odoo doesn't officially support python 2
anymore.
closesodoo/odoo#28519
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
This problem appears when the module l10n_be_hr_payroll_fleet is installed with the
dynamic report for employees (enterprise module hr_contract_reports).
This module inherits from hr.contract and will create and modify some fields.
By modifying contract's table, PostgreSQL will drop the view from
hr_contract_employee_report. At the end of the installation, PostgreSQL will
check if tables exist, it isn't the case for the view from
hr_contract_employee_report, so it will recreate it.
It's the normal behavior.
But when a table is missing, a warning is logged and create problem with
Runbot. For this reason, it's better to log an Info and not a Warning message.
Validated with @rco
This is necessary to get --dev=xml working on windows, because the xml
import uses normcase in file_open and the case normalized filename is
then used to find the addon path (which was not found before on windows)
With this fix arch_fs is now correctly filled in windows and --dev=xml
works.
closesodoo/odoo#28331
Xavier-Do