From now update_json route with display=1 return the cart_qty and not False.
It is usefull withtout extra cost for other modules like wishlist or ... that
previously render all the template just to know the new qty.
Now you cannot arrive on payment page withtout product in your cart and get a
blank page, you are now redirected to the /shop/cart page
When the order are altered due to a change of stock availibilities, we now log
it into the order_line itself or the saloe_order if a line has been deleted.
That permit to display the warning later when the user come back to one of the
page that display the cart resume. (/shop/cart or /shop/payment at this moment).
Remove useless empty file
Make xpath correctly using wrap feature and don't re-copy all contents
Replace old base.get_context with web_editor.context
Product templates already use activities. However due to view inheritance
user can (try to) schedule activities on products. Those are not correctly
computed and displayed.
This commit somehow fixes that. It adds activity mixin on product itself
so that products have their own activities.
Due to inheritance mechanism activities on templates and product are
separated. This is a technical limitation and let us consider that as
a wow effect. Do you want a rainbowman ?
Purpose
=======
Now if we want to create a product supplier info, it's impossible to select the template if it has no variant, which is rather annoying.
Specification
=============
Remove the attrs
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
1. Create an attribute with create_variant boolean un-ticked (ie. don't
create variants from these attributes). For example 'Test Attribute'
2. Create attribute values related to the above attribute. For example
'Test 1', 'Test 2', etc
3. Create a product (product.template) and assign an attribute (eg.
Color: black and white)
4. On one of the product variants, add one of the attribute values for
the attribute we've created in step 2 to the attribute_value_ids
field to allow for filtering by product attributes that do not create
variants.
5. Go back to product template and add another attribute value to an
attribute where create_variant is True (eg. Memory: 16 GB)
6. Our value from attribute_value_ids is gone, and the product has been
deactivated
When attributes are set with create_variant is False, they are
obviously not used to create variants. Therefore, when we are looking
for existing variants, we should filter out these attributes.
Partially closes#18682
opw-762743
Dominican team is focused on Transifex traductions using es.po,
as es_DO.po has a lot of issues in the website and reviewed strings
with wrong wording and mixing english and spanish. From now on
Dominican Republic will inherit es.po and just make specific changes
on github just in the needed words or setences that change base on
region.
Closes#18834
Purpose
=======
Issue: Product_id field should be visible only when product has more than one variant
Here's how it can be reproduced,
Assign user with group group_product_variant
Create a product without any variant
In this case, the product_id field won't be shown in product.template's internal form view for product.supplierinfo, that's working fine. But, now, as this fix is reverted, the product_id field will be visible in product.template's internal tree view for product.supplierinfo.
- Show Product(product.supplierinfo) field when product has more than one variants.
- Improve tooltip on Product(product.supplierinfo) and 'Cost'(product.template) fields.
- Hide 'Cost'(product.template) field when product has more than one variant
Purpose
=======
1. There is some confusion between the vendor price and the cost price of a product. The goal of this task is to clarify it for users.
2. Some users would like to set up vendor prices specific to a variant, the goal of this task is to allow them to do that.
Specification
=============
- Add a clear tooltip on the Cost field (standard_price) : "The cost price is used to valuate your inventory."
- When creating variants, it is impossible to set the cost of the product variant, it always resets to 0. It should be hidden if the product has some variants
- Add product_id o2m in vendors form, tree view on product template, and same field should be displayed on variant form view (the field is not required)
- Product_id field visible only when product has more than one variant
- Add a tooltip on this field : "If not set, the vendor price will apply to all variants of this products."
- Vendor price calculation for automated generated RFQ (should be based on sequence: take the first vendor price that matches all the conditions)
Steps to reproduce the bug:
On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have
several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based
on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Go to the debug menu > Edit Action and add the value 'uom': 1 in the context field
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists
proposal, open the list of proposed pricelists, and select the pricelist
Bug:
The wrong value was sometimes displayed in the price field. To be more exact, the displayed
value for each product.template was the price of the product.product that has the same id.
If a product.template has an id which doesn't exist in the product_product table,
this product disapears from the list.
opw:762663
Steps to reproduce the bug:
-On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists proposal,
open the list of proposed pricelists, and select the pricelist
Bug:
A traceback was raised.
opw:762663
Jeremy Kersten