| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The API of `Registry` has been modified as follows:
- `Registry(name)` returns the registry of the given database
- `Registry.new(name)` forces the creation of a new `Registry` object
- `Registry.delete(name)` discards the given registry
- `Registry.delete_all()` discards all registries
- `registry.setup_signaling()` initializes the signaling for `registry`
- `registry.check_signaling()` returns an up-to-date `registry`
- `registry.signal_registry_change()` notifies that `registry` has changed
- `registry.signal_caches_change()` notifies potential cache invalidation
|
|
Also, convert function `init_models` to a registry method.
|
|
The routing map should be static. Being calling from the old api (with registry)
there was no problem. But since the new API works with instance, a new instance
of the ir.http model will recreate its own routing map. This should have been
avoid during migration to new api of ir.http . Anyway, this prevent many mistake
for the website migration.
|
|
a7c1f371974f1295d0640d4d82d727aa878ae37b was a bit on the noisy side
|
|
|
|
|
|
|
|
|
|
Uninstalled modules are skipped with the filtering on the state.
Fixes #9768, Closes #11378
|
|
|
|
|
|
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`
|
|
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`
config option is a single-use flag, so we
have to pop it from the config after using it.
A more complete refactoring is needed to
remove all uses or tools.config as a
global "context" for passing parameters.
|
|
|
|
This reverts commit ca7eeb0ed0449755ef978512deb1c4827b773026, which
introduced a regression where, in some situations, an attempt to serve
an asset could be done before the routing map could be generated,
resulting in a 404 and a failure to load the web client.
|
|
The function invokes methods `_auto_init`, `init` and `_auto_end` on models,
and now uses the new API. This enables to define those methods in the new API.
|
|
Is currently a function emulating a lazy property.
|
|
post_init_hook and tests phase
|
|
|
|
- remove deprecated tree_but_open ir.values
- remove magic ir_ui_menu delete at loading
- remove unused icon and web_icon_hover
|
|
|
|
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.
|
|
cbb51610ee1506e67f5aaab703130ff8a2d824b6
|
|
Too many people copy-past this line without understand !
|
|
|
|
|
|
|
|
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.
|
|
|
|
Let 2015 be a year without modelines!
cf #4174
|
|
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
|
|
The fix consists in this: when setting up models, ignore manual fields that
refer to unknown models if all models have not been loaded yet.
|
|
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
|
|
|
|
Simplify website crawler using the generic HTTPCase opener
|
|
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.
|
|
|
|
|
|
|
|
Launchpad bug: https://bugs.launchpad.net/ocb-server/+bug/1319285
|
