When launching a server with two similar addons path, e.g.:
- /home/alice/dev
- /home/alice/devodoo
launching the server in dev mode may crash due to the poor matching using
`path.startswith(...)` method which may make `/home/alice/devodoo/bob/main.xml`
match in addons folder `/home/alice/dev` and with a non-exitant local path
`odoo/bob/main.xml`.
Instead of relying on the name, use the `os.path.commonprefix()` method to match
on real paths and avoid partial matching.
commonprefix will only work if the folder name ends with the appropriate
separator (which is not guarantee for a user provided addons-path) so force a
trailing `/` using os.path.join(..., '')`.
Closes#12359
Related and function manual fields may not be loadable during initial
setup (partial=True) due to dependencies being not loaded. Ignore
theses fields during partial loading.
When loading the registry, the parent store are defered at the end of
the registry initialisation. However, when modules should be removed, a
brand new registry is build without deleted modules, losing the list of
models on which parent store should be recomputed.
According to PEP302, the signature of `Finder.find_module` should be
`find_module(fullname, path=None)`.
Ever since it was introduced in 64ec5f36df the addons import hook
defines the second parameter as mandatory, which is an issue for
systems relying on the specified behaviour (and not needing to
provide a path) like the stdlib's `pkgutil.find_loader`.
fixes#10670
During database creation via the database manager,
or when using the startup option `--load-language`,
the selected language(s) will be installed as soon
as either:
- the base module is installed/updated (because
base_data.xml includes a call to res.lang.install_lang()
- the registry is loaded (after loading `base`,
the system installs the requested languages, even
if the server is not in update/install mode)
This is implemented by passing a global config
option `load_lang
This behavior was modified as of saas-7 by PR
for the command-line and for the database manager.
In both cases, we don't want the installation
to be repeated the next time either of these
event occur. Essentially the `load_language`
The goal is to avoid recomputing field several times. Consider, for instance,
two fields F and G, such that G depends on F. Suppose that G is recomputed
before F. Saving G to database proceeds well, but when F is saved to database,
G is invalidated and marked for recomputation. Field G is possibly recomputed
twice on some records.
Avoid this situation by chosing a field such that none of its dependencies must
be recomputed; use a topological sort based on field dependencies for that
purpose. In the example above, G will never be recomputed before F.
In test mode, only one cursor is available, and longpolling will take
it, and not give it back before 60s, causing a phantomjs timeout. This
commit simply return an error when the server is in test mode.
Sadly, I had to patch the web client to prevent logging the error in
this case, because that's the way phantomjs detect if there is a
problem.
When a new field has to be computed for the first time on existing records,
mark that field as todo, invalidate it in cache, and perform all recomputations
at once at the very end.
The `unittest2` package is simply a backport of `unittest` from the
Standard Library of Python 2.7 to previous versions.
There is no reason to use it any longer.
Closes#6941
When a model is set up, it can retrieve fields from a similar model (with the
same base classes). Only proper (not inherited), regular (non-related) fields
can be shared that way, since other fields may depend on other models.
New installation was detected using the `installed_version` attribute
(`latest_version` in `ir_module_module` table), but this field wasn't
reset at module uninstallation (now fixed by cb29f9e) avoiding
execution of hooks.
Same logic was applied for migration scripts at 8ff7230.
Fixes#7708
Rename the field 'osv_memory' on 'ir.model' into 'transient', and make it a
regular field instead of a computed one. When instantiating a custom model,
use its value to make transient models.
This commit alone will make your server crash on an existing database. A small
database migration is needed: simply add a boolean column `transient` (with
default value false) in table `ir_model`.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
The patch speeds up the cache invalidation in the registry, and make most
models use the generic method `clear_caches` instead of specific `clear_cache`
methods.
The lazy property `pure_function_fields` was not invalidated upon every setup
of models, and hence could contain old instances of fields. As every model
setup re-creates instances of fields, the property has to be recomputed.
A cross-registry cache was introduced by e2ea691ce.
The initial idea was praiseworthy but sub-optimal for servers with a
lot of registries.
When there is lot of registry loaded, the cache size was huge and
clearing some entries took a lot of CPU time, increasing the chances
of timeout.
Also, the cache was not cleaned when a registry is removed from
registry LRU (this operation would also consume time).
The registry size is now assumed to be around 10Mb, and ormcache size is
proportional to the maximum number of registries. Statistics about ormcache
usage is shown to the log when receiving signal SIGUSR1.
The ormcache is now shared among registries. The cached methods use keys like
(DBNAME, MODELNAME, METHOD, args...). This allows registries with high load to
use more cache than other registries.
The model setup sometimes misses entries in _inherit_fields and _all_columns.
This is because those dictionaries are computed from parent models which are
not guaranteed to be completely set up: sometimes a parent field is only
partially set up, and columns are missing (they are generated from fields after
their setup).
To avoid this bug, the setup has been split in three phases:
(1) determine all inherited and custom fields on models;
(2) setup fields, except for recomputation triggers, and generate columns;
(3) add recomputation triggers and complete the setup of the model.
Making these three phases explicit brings good invariants:
- when setting up a field, all models know all their fields;
- when adding recomputation triggers, you know that fields have been set up.
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
* document and warn that checks and fast_suite in tests sub-packages are
deprecated and have no effect
* avoid iterating all currently loaded modules when looking for test
modules in a tests sub-package
* replace use of __import__ by importlib
Fixes#3152
When loading the registry without any module installation/upgrade, models are
set up once instead of twice. In other cases, models are always set up before
installations/upgrades.
Jairo Llopis