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.
- let the user choose between the pg_dump custom format or the zip format including the filestore
- use file objects to allow dumps larger than memory
- postgres subprocess invocation is now clean and thread-safe, we dont touch the local process environ anymore
- add a manifest to the zip dump format with version information about odoo, postgres (pg_dump doesnt output it) and modules
The first term of a po file is a comment for translator e.g.:
msgid ""
msgstr ""
"Project-Id-Version: openobject-addons\n"
...
This comment is ignored if there is no source and it is the first term of the po
file. The first flage was disabled too late and if the following terms also
started with an empty source (for too long terms), they were skipped as well.
Disable the flag as soon as the condition is evaluated to make sure no
additional terms are ignored. opw 619786
In case of different directory for stroing po and pot files than 'i18n'
(e.g. 'i18n_extra'), a po could be linked to a wrong pot file.
Use the same folder as the po file to look for pot.
Fixes#4326
In [f04f409], the configmanager's __init__ lost its fname kwarg, which
allows to pass the name of the config file to read (or write).
Without it the only way to programmatically specify this file name is to
use the OPENERP_SERVER environment variable, which may be unpractical and/or
subject to renaming.
External tools (such as the buildout recipe) may need to pass this file in a
clean way.
* Odoo installation from packages or source
* Deployment instructions for production environments
* dbfilter
Add missing support for disabling xmlrpc(/http), useful for WSGI
deployments which require running cron-only Odoo instances.
User-provided addons paths are checked for existence (and rejected), but
default addons paths are not checked, and blow up when trying to listdir
them (e.g. when http.py tries to load modules).
This is an issue when using Odoo from the distributed tarballs, because
the packaging currently moves all modules to openerp/addons and removes
the root ("main") addons directory.
Before, all isolated (between xml/html tags) two chars words coming from views were not translated (by choice).
But, for some words, allowing them is useful. For instance, the word 'or' located between two buttons.
opw-616716
Used to be the first line was the CSV headers, the slice was left over after
these were removed from the source data. It probably didn't hurt (only issue
would be if the first module — alphabetically — has a single translatable
term), but it's just as clean not to have that.
Also removed now-unused variable (probably leftover of the CSV thing as well)
For instance, when a context was passed to a method, but no lang was defined in the context, it did not tried to fallback to other places where we could have find the user language.
Without this fix, if you have a new view in a module with active=False, the active tag will be ignore when upgrading the module because of 'update' mode, and the view will be activated by default !
commit f76d4525a was not actually working: extra keys from
config files are not yet into the config options dict at
import time. The fix is to move the logic inside the method,
like in `find_pg_tool` just below.
Also fix the use of `find_in_path` in report.py: the subprocess
may also raise AttributeError exception, so instead of listing
all the possible ones just re-raise the IOError shallowed by
`find_in_path` when the result is None.
Fixes#3809#3811
The openerp-server.conf now generates the bin_path record, in order
to resolve calls to external binaries served in the thirdparty dir.
Adpated report.py to use find_in_path and not directly which.
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
When working with a large number of databases, the memory allocated to
registries wasn't limited, resulting to waste memory (especially in the
longpolling worker, which is not recycled).
The size of the LRU is depending on the soft limit configured for
workers.
Commit 57ad514b makes the function preserve the aspect ration of the
original picture. Error of mine because the expected behavior was to
lose it for kanban view purpose.
For backward compatibility sake, this commit will keep the old behavior
by default.