| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
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).
closes odoo/odoo#34268
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
closes odoo/odoo#30614
|
|
|
|
|
|
This reverts commit 5f4a9451828fff1919c74e421001bc111c5c138d.
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
closes odoo/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.
closes odoo/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.
closes odoo/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 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.
closes odoo/odoo#28331
|
|
|
|
closes odoo/odoo#28255
|
|
|
|
Migration files must contain `-` in its name for being executed
|
|
|
|
opw-1896028
closes odoo/odoo#27945
|
|
Do not propagate cache invalidations to other workers when simply loading the
registry. Only do it when installing/upgrading/uninstalling modules.
|
|
After a module upgrade, validate the architecture of the module's views that
are impacted by updates, but have not been checked yet. Before this patch,
views were checked twice on average.
This patch speeds up the installation of modules by about 15% without demo
data. With demo data, the speedup is around 10%.
|
|
The registry loading system should not alter databases unless it is
asked to do so, by a module installation or update instruction.
This property should hold true as well for database bootstrap, and this
is what this commit changes..
In order to avoid any behavior change for command-line users, an
implicit `-i base` is assumed when starting the server from the
command-line with `-d <db>`, causing the db boostrap to happen if the
database did not exist yet.
|
|
This is simpler, cleaner, and has a smaller memory footprint.
|
|
Non applicable since b0646f9d2c983481f20bea31f8f6427bbfccb245.
This reverts commit 03395ea103f1e933576bad2a32ae7842818e7dfd.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Backport 9ec0455abc041b855dcab18e8e185baf806b9f14 and
6a601fe6dc848cdeca2ab8429210e3b5087275d9 as they fixed various
possible NameError but did so in later sub-releases.
|
|
Task 1856935
Currently, if installing a module's demo data fails (because the
module was uninstalled and some were left over and can't be
reinstalled, or because they're broken, or…) the installation of the
module fails and further installations are skipped (?).
Since demo data are non-essential (though required to run tests),
rather than fail everything if they fail just roll them back and
notify the user.
This change generates a warning log *and* shows a notification popup
to the end user.
|
|
Try to remove cr.commit (and rollback) from module and db install:
* put a savepoint around test data loading
* remove a bunch of commits sprinkled throughout
* remove rollback on data loading failure (assuming it bubbles up, the
entire module's installation should be rolled back)
* add commit right before the tests are run, so they can run isolated
and still see whatever was done when installing their module
* convert a few explicit closing to context managers
|
|
Intended for demo / throwaway databases only
Task-ID: 1856493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Note: 1aacc962620982528a3dfc90d2c1dd0027359375 has been ignored and will
be forward-ported later
|
|
|
|
|
