Problem: the update of custom models/fields is not fully transactional, and may
potentially lead to an inconsistent database. An other problem is creating two
custom fields by writing on a model: if the second one fails, the first one has
been committed without notice. Retrying the request will give an unexpected
error (duplicate field name).
Solution: never commit in the middle of a request. If the changes have an
impact on the registry, then mark it as invalid (with a new flag), and signal
registry invalidation after everything has been committed. If the request
fails, reset the registry. Both registry and cache invalidation are handled
the same way.
When adding a field on a model, only the _inherit were checked, not the _inherits.
This commit fixes the following bug:
1. install `sale` (adding the field `sale_order_count` on `res.partner`)
- field `sale_order_count` is created on `res.partner`
- the ir.model.field is tagged with module `sale`
2. install `point_of_sale` (adding another field on `res.users`)
- field `sale_order_count` is created on `res.users`
- the ir.model.field is tagged with module `point_of_sale`
When installing sale, the model res.partner is returned in the list of impacted
models, on which _create_fields method is called but not res.users.
A direct consequence of this bug is that, the fields translations are in the
wrong module. May fix some uninstallation bugs too.
Closes#16104
Demoted to library in Python 3, see if uses can be replaced by more
specific construct, just import functools.reduce otherwise.
Futurize fixers:
* lib2to3.fixes.fix_reduce
Move the post-install tests execution outside `Registry.new`, and add a flag on
class `HttpCase` to enable/disable the registry "test mode".
This allows a test to run actual transactions that will reload the registry,
which may be used to test the creation of `ir.model` instances, etc.
As discussed on issue #15225, it should be possible for system administrators
to disable the 1-click installation system.
The plan is to disable the feature by default, but make it relatively easy
to turn on when it is explicitly desired.
1. At the moment we cannot guarantee that all Apps published on the Odoo Apps
Store are safe. And it is a security risk to let end-users deploy Python
code on their Odoo servers without requiring any review/deployment by a
competent system administrator.
We will work on improving the validation process of the Store, but this
will require time, and won't probably be a 100% safe process in any case.
2. The one-click install feature is however really useful to help
non-technical users install Apps, as long as the feature has been
explicitly allowed by the system administrator. This is a common feature
in other software suites as well. So we'd like to keep it as an opt-in
feature.
3. Administrators of multi-tenant servers, cloud hosting services, etc.
understandably expect to be able to turn off the feature for
security/control reasons.
4. By turning off the feature by default, but still exposing it in the UI,
we keep it *discoverable* for users. The error message should be
helpful to direct users to their sysadmins.
5. By using the permissions of the download folder as a flag for turning
off the feature, we avoid introducing an extra server parameter.
The folder is still created (read-only) by default, for the sole purpose
of making it easier to locate.
Fixes#15225
After modifying the database schema, if some models do not have a table/view,
attempt to recreate it by calling their method `init()`, following inter-model
dependencies.
Fix the model `board.board` by making it an abstract model.
Add the missing model dependencies on report `crm.partner.report.assign` to make
it depend on report `account.invoice.report`.
by auto-extending addons path with odoo.addons.__path__.
This patch also introduce
* an explicit declaration of odoo.addons as a namespace package
This is necessary because the standard way of declaring namespace
packages in setup.py does not work as long as odoo/__init__.py
contains code.
* a more reliable way to find odoo root path.
- As of v10, manifest files should be named `__manifest__.py`
- For backwards-compatibility, __openerp__.py manifest files
will still be supported for the time being
- Limited refactoring, to add support for the 2 different
naming conventions
- All textual references to __openerp_.py updated in
documentation and examples
Manifest files are literal Python dictionaries, and
aren't supposed to contain expressions that require
a full-fledged eval.
`literal_eval` is therefore sufficient *and* safer.
This parsing method was already used when listing addons
during startup of the Root controller (http.py, load_addons())
Raphael Collet