This revision is related to 93d4db9d1e.
Usually, for models with an image, the original `image` is stored
in the field `image`, and then the resized value are in the fields
`image_medium` & `image_small`.
In the specific case of the product variant, this is not the case,
the original image is stored in the field `image_variant`,
and the `image` field uses as well the method `_get_image_variant`.
The `image_get_resized_images` must therefore return the "big image"
as well, which is returned with the key `image`, by default.
This is done using the method argument `return_big`.
This is possible to set an image for a specific variant
When this was the case, the image displayed was always the
image within its original size, it wasn't resized
to small and medium sizes.
opw-657055
applied_on:
The field applied_on in pricelist rules is not taken into account:
- In the price computation
- In the name computation
When creating a pricelist item, if you select (applied_on = Product)
first and set a product, then select (applied_on = Global), and save the
rule, the computation will still take the product_tmpl_id in the price
computation.
Instead of fixing the whole _price_rule_get_multi method, this patch
sets the fields that should not be taken into account to False.
compute_price:
Add a behavior similar to the applied_on field, to reset unnecessary
fields to zero when the computation method is changed.
Original idea from @tgr-odoo
opw-657148
Closes#9671
In v8.0, a procurement is not created by default. Only sale_stock and
sale_service will create procurements, since they are only used for
physical products or task-related services.
In v9.0, the behavior was changed and a procurement was always created.
This is not necessary, since the procurements are still only used for
physical products and task-related services. This behavior will just
lead to the creation of procurements which will fall into exception
(method `_assign` will return False).
This fix switches back to the previous behavior. The other solution was
to prevent the exception, but it will imply that useless procurements
will pile up.
opw-654363
This commit introduces the suggestion of a minimum quantity for the
chosen vendor. The minimum quantity is suggested only if the quantity on
the line is zero. It still allows the user to set a quantity smaller
than the minimum quantity for the given vendor.
opw-654300
Issue: when the user create a pricelist item, the function fields (name, price) are updated only on save (the form view) and not on change.
In the pricelist form view, the 'item_ids' one2many receive empty value from the modal (name, price).
Fix: update 'name' and 'price' field to the new v8 api.
This revision adds the possibility to use the key
`default_category_id` in the context to set
the UoM category when quick creating a new UoM,
like it's the case everywhere else with the
`default_*` keys passed in the context.
Closes#4407
The function field selected_seller_id is removed and must be replaced
by a direct call to method `_select_seller`. This is more conventional
than the previous 'browse with context' way of doing.
We introduce a new field on supplierinfo: product_id. Thanks to this
field, the vendor information which will be used in a purchase order can
be specific to the product variant.
In v8, some fields were added for the product.pricelist formview by
template inheritance : after the active field. For v9, this active
field was moved in a button_box button (archive stat_button), so the
added fields (inheritance) landed in the stat_button too.
* Group with 6 columns caused problem when inside a dialog because of
wrong use of labels.
* Use o_row to align input followed by a '%' sign.
* col=6 group should not be in a parent group (moreover: this group was
alone in this parent group).
With the new pricelist system, a price should be specified for any
supplier, otherwise the price chosen for a PO is zero.
Also add unit price for existing PO
As the standard price on the product template changed towards the product variant,
we should also change the product price history to be by variant.
Also the inventory value calculated in the Stock Valuation report should be by variant.
Martin Trigaux