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`
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
- 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.
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.
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.
Loading views for custom models from module data files was not possible because
custom models and fields were introduced into the registry after all modules
were loaded. As a consequence, the view architecture did not pass the checks.
This patch takes a different approach: custom models and fields are loaded
early on in the registry, so that views can be validated. The trick is to take
special care of relational custom fields: we skip them if their comodel does
not appear in the registry. This allows to install and upgrade modules that
create/modify custom models, fields and views for them.
This simple optimization in load_marked_modules() avoids unnecessary calls to
load_module_graph(). This provides a small speedup, and avoids confusing log:
some module updates were making it look like the registry was loaded 5 times
instead of once.
If the server was started without -i or -u and
happened to initialize a fresh database,
auto-installed modules that depend
on `base` only would stay in status "to install"
without actually being installed (until the next
installation round was triggered).
This was of little consequence in 7.0, but causes
a crash in 8.0.
Fixes#953
It's broken (though easy to fix) and not very useful, if third parties want to
create databases asynchronously they can handle the asynchronicity on the
client-side (an HTTP request is easy to make asynchronously after all) and
call the synchronous `create_database()`.
fixes#1137, after a fashion
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Add a loglevel 25 to log some INFO to runbot
Add timers for loading and testing
Silence empty test suite
ir_logging use relative pathname, warning this doesnt work for --addons-path modules yet.
Since 4ec71c74d1, migration scripts
are not executed at module install anymore.
As this behavior was missused as "init" scripts (see [1]), this
commit re-add this possiblity via hooks.
There are 3 hooks that can be declared in the manifest file:
- pre_init_hook: called before module installation
- post_init_hook: called after module installation
- uninstall_hook: called before module uninstallation
Like the "post_load" manifest option, the values for these hooks
must be a string containing the name of a method available at the
module root.
The signatures of these functions are:
- (cr) for pre_init_hook
- (cr, registry) for post_init_hook and uninstall_hook
[1] https://bugs.launchpad.net/openobject-server/+bug/1314680
When the registry is updating, the view verification only validates the views
from initialized modules. Not taking the current module allow update of views
that have also an inherited view in the same module. The verification of the base view
must not try to apply the old inherited view against it as it may not be applicable
anymore.
After module update, we re-validate all the views of this module. This is needed because
a module can declare two (or more) inherited views that are correct when applyed alone,
but not when combined with others.
bzr revid: chs@openerp.com-20140418141550-7b57b1xl4fx0rgqq
remove deprecated zipfile support
add preload_registry option when server is running
allow registries to be used in contruction in test mode
add a rollback test case for http tests
add a phantomjs helper
bzr revid: al@openerp.com-20140209004005-p5pwym4sqc23vw5b
Christophe Simonis