At 96f038a product-related fields were removed due
to an important product.template/product.product
refactoring. As the field values were simply
dropped, they may not be nullified when upgrading an
existing database. Forcing them to False will take
care of it.
Cascading onchanges can be caused by a related field computed in cache. This
causes a bug in sale order lines, were setting the uom field forces reading
product fields, which are inherited from product templates. The inherited
fields are computed as related fields, which marks the product record as dirty.
This subsequently triggers an onchange on the product field, which resets the
uom field!
Before this, the div wasn't in the right place in the form view
for instance, in the product form view, the third checkbox triggered this binary upload file
opw-613318
task-8982
This fixes issue #2146. The inverse of a one2many field can be an inherited
field (_inherits). In that case, we cannot read its value with a simple
database query. Instead, we let the related field read it, but for performance
considerations we disable the prefetching of other fields.
The mapping old api → new api mistakenly takes the last positional argument as
the context (fields_view_get() has an extra parameter after context.)
Fixes issue #2063
When no order is forced, it's more user-friendly if the products are ordered by alphabetical order.
This will mainly be applied:
* In the list view in the back-end
* In the eCommerce, for products with equal website_sequence
The context may be inconsistent (for instance, containing a group_by associated to another
model). The client will take care of keeping it consistent. Fixes issue #1768
The methods product_id_change() and uos_id_change() have been converted to the
new api, and now use the decorator @multi. When invoked with the old api, by
convention the methods will take the last argument as the context. But this
will not work properly for those methods, as the context is passed in another
position. In order to avoid an argument swap in the api wrapper, we moved the
context to its expected position.
Fixes#1943
The compatibility issue with auth_ldap has been
fixed and the default key derivation function
switched to PKDF2+SHA512. `auth_signup` provides
a password reset mechanism that can be used in
combination with `auth_crypt`.
Browsers add different width to input of file type, messing up the usability of the
product formview placing a 'phantom' box in front of the options. Added a specific
css rule for this case.
This patch is related to 82adba4714
With the above patch, it wasn't possible anymore to save if an onchange failed. This isn't the expected behavior.
Besides, $.when.apply($, defs) is rejected as soon as one def fails, without waiting other defs to be either resolved or rejected.
This new patch allows to save if onchange fails, and wait for onchanges sequentially.
Sometimes a cached bundled could be missing in the
ir.attachment filestore (for example after copying
a database for test purposes without duplicating
the filestore as well).
When this happens ir.attachment will return an empty
file contents ; treat this as a cache miss.
This means empty bundles would not be cached, which
is not a big issue - there is little benefit in
caching them, and they should not be common nor
useful.
When deleting filesystem-backed attachements, the
deletion on the file-system is not transactional.
In the event of a transaction rollback, the file
deletion would not be rolled back, which is a
dangerous side-effect.
This can happen for example when several transactions
try to delete the same file(s) at the same time.
The duplicate deletions might be detected by the
database (being concurrent update errors), and rolled
back at the point of the DELETE query, to be retried.
If the files have already been deleted in the file
system it before the rollback, it leaves the system
in an inconsistent state, at least temporarily.
One case where we have seen it is when web bundles
are loaded by many web users at the same time, right
after being updated (and thus invalidated).
As they are currently cached as ir.attachment records,
this often causes a corruption of the cache.