when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
Not passing the context should be exceptional, in almost all cases you should pass it.
In this specific case, not passing it will, for instance,
prevent the use of the key 'active_test' in the context,
and there is therefore no way to count all variants, including disabled ones.
If a selection field is created with an empty list of choices (e.g. added by
submodules), initialise the field as a varchar column (most common).
Check if the list exists to avoid crashing while checking the type of the first
key.
Fixes#3810
This rev. is comparable to 0b18a5afec
The action action_order_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 the 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 probably be performed in master.
On one hand, when a product attribute is shared by several
products, some may use different subsets of its possible values.
On the other hand, when less than 2 values are enabled for
a given attribute on a product, no choice is displayed for
that attribute on the shop page, as there is none to be made.
The way those "visible attributes" were computed in
get_attribute_values() was wrong: when counting the
number of values it used the whole range of possible
values for this attribute (cross-product), not just
those enabled for that product.
This lead to inconsistencies vs the website_sale.variants
template, and products using a single value out of a larger
range of values were constantly marked as "Not available"
in the shop.
The next post button at the bottom of an article was stuck when getting to
the last page. A cookie storing the *all* the visited posts was used
to determine the next one according to a non-stored (so not working) and
unexpected criteria 'ranking'. Also could get articles from other blog.
Instead of this whole broken logic, simple loop through articles by classic
order and go back to first one when at the end.
Better looping algorithm can be used in master where ranking is stored.
Fixes#3097, opw 614559
The renaming was done in 2 passes during the new WMS
implementation, and the @oldname attribute was ommitted
at rev.386f7c1212705a9cc3b2e73731bfcc4ca447dfbf
In currencies, advanced search with "equals" or "not equals" on rates
was not possible for something else than a date, in server format (crash).
This is because the name field of the model res.currency.rate is a date
This is now possible to search rates with just a float and the equal operators,
it returns currencies which are having at least one rate set to this float value
This is also possible to search rates with the equal operators with a date in
user (context) date format.
If the variable was existing outside the context of the ``foreach``,
the value is copied at the end of the foreach into the global context.
Fix#4461 - Q74531 - Q71486 - Q71675
The email_from for the order confirmation email in the ecommerce
was forced to the company email,
preventing any customisation concerning the from email address
in the sale order mail template.
When fetching the VAT reports for several periods, only the last period was took into account
This is due to the fact that a browse record assignation no longer works in Odoo 8.0 API
at least not the same way.
code.sum_period = sum_tax_add just do nothing in Odoo 8.0.
Besides, using the variable "code" outside its loop is kinda crappy.
When returning an HTTPException e.g. by calling ``request.not_found()``
which returns a ``werkzeug.exceptions.NotFound()``, the http system
would log a warning as HTTPException is neither a subclass of Odoo's
Response nor a subclass of werkzeug's BaseResponse.
Move the string response case about (for flow clarity), and convert
HTTPException instances to Werkzeug responses then fall into the normal
BaseResponse -> Response case to ultimately get an Odoo response object
out of the HTTPException instance.
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)