Original code assumed the empty field would be missing or an empty
string, b64decoding an empty string yields an other empty string which
triggered a "not found" response.
However Odoo returns ``False`` in case of an empty field, so that needs
to be replaced by an empty string before decoding, as b64decode doesn't
accept booleans as input (for some reason...)
In case of an empty inline column, a Download link inviting the user to
click would still be rendered (erroring out if the user eventually
clicked on it)
fixes#3684
When changing the type of a column (if size differs for example),
'selection' field should be considered like a 'char' field (since they
are internaly the same column type)
This will fix some migration issues where 'char' fields were correctly
changed but not 'selection,' field.
Use case:
* create a 6.0 db with 'stock' module installed
* 'state' field in 'stock.move' model is of type 'character varying(16)'
* migrate it to 8.0
* 'state' field is still 'character varying(16)' but should normally be
'character varying'
This was broken by mistake at rev. d6c6f31231
partially undoing the introduction of this feature at
rev. 49c0ed6467 (probably due to the
confusing name of that manifest option)
In cases where data is directly given to the saveas_ajax controller,
the filename was not correctly set, as no read method was performed.
(The read call is useless as the data is already avaiable in such a case)
In such cases, the filename must be given in advance
opw-626707
Acting as a mailing-list-like distribution system, the system used
to set the enveloper sender (aka bounce address) to the From header
of the message, effectively pretending to be the original sender.
In some cases the domain of the From header explicitly forbids
sending emails from external systems (e.g. with a hardfail SPF
record), so this could cause the email to be rejected by some
spam filters, depending on their policies.
The system will now use a local bounce address in the form:
mail-catchall-alias@mail-catchall-domain
or, if no catchall is configured:
postmaster-odoo@mail-catchall-domain
(as soon there is a mail.catchall.domain configured)
It will only fallback to using the From header when no
catchall domain is configured.
Fixes issue #3347.
Closes#3393.
When setting a float field,
the web client rounds the value entered by the user
using the instance.web.round_decimals method.
Nevertheless, this is possible that this method returns unrounded float,
due to the float precision
For example, round_decimals(53.8, 2) returns 53.800000000000004
In order to compare this new float value to the old float value
and check the eventual change),
we need to check if the delta between the two is almost 0.
This is the goal of the float_is_zero method introduced during this rev.
which is comparable to the float_is_zero method
already available in the openerp server, in openerp.tools.
Float values compared using the simple === operator
instead of this float_is_zero method
will be regarded as different in some cases,
according to the float value and the precision
And the value of the field will be regarded as changed,
which can lead to unwanted triggers of onchanges.
opw-626635
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)
- When the partner is a company,
the opportunity count should counts the opportunities
of this company and all its contacts
- When the partner is not a company,
the opportunity count should only counts the opportunities
of this lonely partner.
opw-626609
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.
This rev. is related to 8381d47543
The action action_purchase_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes it will active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should be done in master.
The purchases button on product templates open the purchase orders
that have at least one of the variants of the templates
Set in the context of the action button action_purchase_line_product_tree
'search_default_product_id': active_id, 'default_product_id': active_id
as no point, as default_product_id expects a variant id (product.product)
while active_id is a template id (product.template).
opw-626521
On Windows, when having special characters in the month name (For instance, 'décembre'),
the windows odoo server sent non utf8 encoded, which could not be decoded by json dumps
opw-622189
Domain on the action_hr_evaluation_interview_tree has been removed
during rev.fbbe8631c9edb2dacedcb99c1cd7c6bea6f42b33
We force an empty domain in order to remove the domain from the window action
for migrated database, coming from 7.0.
For companies not working with variants,
it is important to be able to search in the
Products menu (product.template) using
product codes.
It is useful as well to see the codes
in the default kanban view too, even if
it is only the code of the first variant.
When a stale XML ID exists in the database, `_update_dummy()`
must consider it as missing entirely, and the next call
to `_update()` will take care of cleaning up the old XML ID.
Failing to do so for `noupdate` records means the `_update`
will never happen, and as soon as another record is created
or updated with a relationship to that stale XML ID, it will
plainly crash the installation/update.
Takes care of resetting it from older versions
e.g. rev d97e7a6a4e
and c0076916f3, as
the old `variants` field that was used does not
exist anymore, crashing at opening.
Completes/improves fd6dde7ca
Because Werkzeug uses/provides flow-control exceptions via
HTTPException (which can be used as straight responses) they are used in
a few places of the web client, when triggering some redirections for
instance.
Breaking into the debugger for such mundane situations is surprising and
inconvenient for developers trying to debug actual issues in the system,
even though HTTPExceptions are by and large not error per-se, and
shouldn't warrant triggering post-mortem debugging.
So in the non-RPC dispatcher, don't post-mortem on HTTPException either.
If the report was printed from the tax codes list
Accounting > Configuration > Taxes > Tax codes
There is no information concerning what should be displayed (periods, details, etc.)
as the user did not printed the report from the wizard
(from Accounting > Reporting > Generic Reporting > Taxes > Taxes report)
We therefore set default values, in order the report to not crash
Nevertheless, the user has obviously to go through the wizard
if he wants to set a configuration different than the default one
While keeping the compatibility for reportlab 2.5.
Splitting the text node on line breaks '\n' leaded to orphans ending tags,
like '</font>', which is regarded by reportlab 3.0 as a paragraph,
and reportlab therefore surrounded these tags by <para> tags,
which leaded to not syntax correct html like
<para></font></para>
To test this patch:
- While having reportlab > 3.0
- Create a rml report containing (at least) '<font>\n</font>'
- Then print the report. It must not crash (obviously)
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Xavier Morel
kevin wang
Denis Ledoux
Raphael Collet
Olivier Laurent
Olivier Dony
Antony Lesuisse
Samus CTO
Manuel Vázquez Acosta
Antoine Lorence
Damien Bouvy
Yenthe666
Frédéric van der Essen
Aaron Bohy
Josse Colpaert
Arthur Maniet
Christophe Simonis
Christophe Simonis