* product.category: remove complete_name field as display_name can be used
where the field was used
* product.supplierinfo: remove computed qty field. This field originally
contained the min_qty computed into the product_uom. However commit
3c186c5807 broke that field without reason.
Since 2011 no one complained about this field being unnecessary, so let us
remove it.
* product.template: shorter and less spaghetti version of create_variant
method
* product_product._sellect_seller: fix use of default parameter in method
kwargs + use odoo standard datetime default value
A new API is introduced for price computing using pricelists. It is simplier
to use in most use cases, which is computing the product price in a given
pricelist. Old methods return dictionnaries and tuples, which are rarely
used in the code.
product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Old price_get method is now replaced by price_compute and ready for migration.
Explicit parameters for unit of measure and currency have been added to ease
code understanding.
product.py and product_views.xml contained code related to several models.
This commit split those files to separate submodels :
* decimal_precision
* product_attribute: product.attribute, product.attribute.value,
product.attribute.line
* product_template: product.template
* product_uom: product.uom and product.uom.categ
* res_currency
Product now contains product.product model, along with some smaller
models (product.packaging, product.supplierinfo, product.category,
product.price.history)
The less refactoring in 5b65befcd8
wrongly removed the css directive that hide some elements in edit mode.
As a side effect, the product price was appearing twice when editing a
product. Commit 44ca4317a9 tempt to fix
it but removed the edition part.
opw:683343
The field state was replaced by ‘active’ in project.project (see commit 9b69184).
However, someone forgot to update the arch for the default list view which
was not longer possible to open.
This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).
Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:
.modal
/ \
... (new S.T.) ... (new S.T.)
/ \
... (new S.T.) ... (new S.T.)
/
.o_list_editable (new S.T.)
/ \
.o_form_view (new S.T.) .table-responsive (new S.T.)
/ | \ \
input input input table (new S.T.)
This explain why the input are not visible: actually, they are displayed
behind the table. In this case the document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004 [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.
The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.
The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.
With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.
This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.
opw 683169
cherry-pick of odoo/enterprise@35f285e50a
[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c7
and never forward-ported to saas-10.
1/ If no docids are passed in get_action (empty list) do not put in context
2/ The method should accept ids or browse records as docids for retrocompatibility.
- The api.v7 method took ids as docids
- The api.v8 method took a browse records 'records' to call the api.v7 method with
'records.ids' as docids
In python, we cannot write 2 functions with the same name that takes differents types
for the same argument. The function 'guess' in api.py will lead to a crash if we expect
a browse record and we send a list
The only way to allow the method to receive different types for the same argument is
to decorate it with '@api.noguess' to prevent any effect from guess method.
That way, we check directly if 'docids' is an id, ids or a browserecord and we always set
a list instead.
Yannick Tivisse