Comments in .po(t) files for translations of type "code" (e.g. field labels)
specify the path to the file containing the translation. This path should be
OS-independent to get the same result whatever the plateform the instance is
running on.
Closes#7561
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Remove languages that were not translated fro, the list of installable languages.
Installing languages with no translations (en_CA) has no effect and having a too
long list is misleading. Sorry Klingon.
Adding languages that were translated but not installable (fr_CA, en_AU)
The server parameter `log-db` gives the possibility
to store the logs of a server in a specific database,
in the ir.logging model.
Unfortunately, it wasn't possible to store these logs within
the database from which the logs came from in a multi databases
environment (e.g. the SAAS).
This revision gives the possibility to store the logs
within the database where the logs come from,
using --log-db=%d (inspired from the --db-filter arg)
We also added the possibility to change the level of logs to store in
the database, with the --log-db-level argument, which is set
by default to `warning`.
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).
In ormcache, those statistic numbers were counted per cached method for all
registries. We introduce separate statistic counters, and create a counter per
(database, model, method). The existing attributes that are no longer used
have been removed.
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.
This will allow to speed up our migration platform: as funzip can pipe
the output of the first file of the archive, even if the file is not
fully unzipped yet. This is useful to plays with dump.sql without waiting
for the full archive decompression.
For public-facing HTML content provided by the user,
`<style>` tags and `style` attributes should be stripped
automatically, as they can easily be abused to deface
pages for abusive users and spammers.
<style> tags were already stripped, the optional `strip_style`
for fields.html enables the automatic stripping of style
attributes.
This is opt-in because custom style attributes are still
desirable in trusted HTML fields.
Variable was added to an error message, then inlined in only one of the
two callsites. Undefined variable error would only appear when an error
is triggered in the actual (postgres-level) backup call.
inserted in ec9a543fixes#5241
Node content of inherited views using <attribute> tags are added
in the translation terms when syncing the terms.
The fact that the content should be translated or not depends
on the content, or to which attribute it refers.
For instance, string attributes should be translated, but
domains probably not.
But, even for domains, this is possible that it requires a translation
e.g. [('category_id.name', 'ilike', 'Customers')].
This domain is very unlikely to be integrated in the standard source code,
but this is possible to have such a domain in a view customization.
Therefore, we provide the possibility to disable the translation
case by case. Setting translation="off" in the attribute of the node
will prevent to add the node content in the translated terms.
opw-625762
Letting PostgreSQL low-level exceptions bubble up
ensures that the mechanism for automatically
retrying transactions will work.
In case of transient errors such as deadlocks or
serialization errors, the transaction will be
transparently retried. Previously they were
transformed into ValueError and caused a permanent
failure immediately.
The fallback to ValueError is meant for invalid
expressions or expressions that use variables not
provided in the evaluation context. Other
exception types should be preserved (this is
further improved in Odoo 8)
Saving log_handler to the config file is not currently special-cased,
the value is thus dumped as the repr() of the list, but not deserialized
with literal_eval. This means -s breaks log_handler and the
configuration file example is incorrect (it looks like a list).
Repeated -s further break the log_handler by interpreting the original
value as a string, putting it into a list, then reserialising that with
repr(), injecting a bunch of escaping backslash. The config file is soon
filled with backslashes and doubles in size with each new -s.
Furthermore for some reason the whole thing breaks --log-handler (and
aliases) entirely, once the wrong log_handler has been saved none of
them works anymore.
Fixes#4552Closes#4157
Saving multiple levels for the same logger should work with few issues,
but over time pathological (basket) cases (e.g. using ``-s`` all the
time) may build pointlessly huge lists in their config file.
Only keep the last level for each logger when saving to a config file.
For log_handler (list of logger configuration specs), having the
configuration file and the CLI configuration be exclusive (one
overwriting the other) is detrimental: it precludes keeping the
configuration file as a convenient baseline and only altering the subset
of loggers of interest at any given time. Combine specs from both
sources instead of overwriting one with the other.
* remove log_handler and its special case from the first options loop
* remove seeding of option with DEFAULT_LOG_HANDLER
* my_default is the baseline "configuration file" value, it's None if
not provided which is not convenient. Use DEFAULT_LOG_HANDLER for it
as baseline configuration file. DEFAULT_LOG_HANDLER isn't a list
anymore, it's a CSV of logger specs (same as file-serialized)
* could actually use a DEFAULT_LOG_HANDLER of ``:`` (the default logger
is root, the default level is info), but that might be a tad too
cryptic
* things are weird between my_default and the file-sourced value,
_parse_config is first run with my_defaults then with the file, but if
there's no file it's re-run with already-parsed my_defaults. So when
the file and the command-line values are of different type,
_parse_config must be ready to handle both
add_option(action=append*) always modifies the ``default`` list
in-place. When using DEFAULT_LOG_HANDLER directly, that means
log_handler is always equal to DEFAULT_LOG_HANDLER since they're the
same list object. Thus the --log-handler command-line would never
overwrite the log_handler value from the configuration file, which is
unexpected
Fix that by copying DEFAULT_LOG_HANDLER before passing it as the
option's default value.
Christophe Simonis
Olivier LAURENT
Temur Vibliani
Martin Trigaux
Raphael Collet
Xavier Morel
Developer Team
Denis Ledoux
belkacem77
Alejandro Santana
Christophe Combelles
Nicolas Lempereur
Dharmraj Jhala
Jos De Graeve
Olivier Dony
Samus CTO
Kiril Vangelovski
Simon Lejeune