It was a bad idea to recompute_coupon_lines into the function 'sale_get_order'.
This function is called several times on each pages. The purpose of this one is
to return a browse record only and IF needed recompute more.
But apply a method that take several secondes will dramastically reduce the
ecommerce performance.
Now, we call the method only when we change the cart and so potentially change
the right to benefit of a coupon or not. And not at each call of the method
'sale_get_order'. In checkout, that reduce from 6 call on some page to one this
costly method that take several seconds.
Before this commit:
Coupon error on cart would always show "Invalid or Expired coupon code"
instead of a more accurate error (eg: already applied, can't use 2 code..).
Plus it would still show the error on page refresh because of the error being
stored in URL param.
Now:
It will show the exact error and since the error is not stored in URL, it won't
be still displayed on page refresh.
This closes#1601
- Add a product (imac 1.799$) and a promo code (eg: 10%) in your cart
- Go to checkout (/shop/cart). You now see 1,619.10 Total and 179.90 discount
- Change product qty (eg: 2)
- Subtotal is now 2x 1.799 - 179.90 instead of 2x 1.799 - 2x 179.90
- Reward line total (discount) is still the same amount (10% on 1 ipad)
Now, we will recompute the discount price based on the entire cart
Note: This behavior was wanted and comes from this commit #87d542
But for the shop, we need to have the reward line being updated on the fly or
it wont make sense for the end user.
This closes #ee4be7a532dd707a0cd19c766dc8e8537dcda242
Before this commit, website_sale_coupon and website_sale_options (which are not
dependant) were both setting an attribute name="t-if" on the same element (same
xpath).
*website_sale_coupon: hide cart line qty widget if line is a coupon
(reward_line)
*website_sale_options: hide cart line qty widget if line is an optional product
The problem was that only one of the condition would be considered:
- On saas-14: always the one from website_sale_coupon, because qweb would
sort inherited views by [priority, name, id]
- On v18: always the one from the last installed module of these 2 would be
considered, because commit #dbb931976fd102a1eceea4ebf195efea7576f260 change
the inherited views order in qweb [priority, id]. Therefore, last installed
module will have higher ID on its view, being interpreted last.
Now, both coupon and optional product lines have their qty correctly hidden.
To do so, we had to change an attribute t-if by an attribute style setting the
display to none. We can't change the xpath to a parent since it is a table
element and it would remove a TD, breaking the HTML. We can't either add a
container because of the themes that may conflicts.
To reproduce on v18:
- Install website_sale_coupon and website_sale_options
- Create a promotion code
- Add item to cart with it's optionnal product and go to checkout
- Add promotion code
- If you installed website_sale_coupon first, the coupon cart line will
display the qty twice (t-if overrided by website_sale_options)
- If you installed website_sale_options first, the optionnal product car
line will display the qty twice (t-if overrided by website_sale_coupon)
To reproduce on saas-14:
- Do the same 4 first steps
- Optional product cart line will display the qty twice
Website_sale_options and website_sale_coupon both xpath and t-if the same
element.
The module that has been installed last will have the upper hand on the
condition and only its condition will be applied.
Now, it correctly take care of both conditions.
Purpose
=======
Currently we are updating the coupon rewards on the fly when creating/modifying/deleting a sales order line.
To avoid multiple searches on res_partners and product to know whether the customer/product is valid on the sale coupon program, we store the applicable customers and products on the program according to the domain defined on it.
This brings 2 issues:
- The customers/products stored on the program are not updated (Was the original spec)
- The checks are numerous and maybe overkill for the given results
Specification
=============
- Don't recompute the reward lines on SO modifications. Add a button to compute the line by hand and make an automatic compute on the SO validation or on the page shop/payment.
- When recomputing the reward lines, make a search on the res_partners and products instead. Now that the action is not triggered so often we can afford to make a search.
- Don't use the fields rule_partners_domain and rule_products_domain. This should be removed in master.
- The field is_public_included is useless now. And we decided to make the coupon available for all the partners if they fit the domain on the program.
On the ecommerce, we may activate an option that allows a user to enter a coupon code related to a pricelist.
On the website_sale_coupon module, we are also able to enter a code to activate a reward related to a program.
Theses 2 boxes may appear on the same page.
This commit merges the 2 boxes into a single one. When a coupon is entered, it will
- Check if a coupon program or a promotion program is linked to this code
- If yes, it applied the reward accordingly
- If not, it will check if a pricelist is linked to this coupon code
- If yes, it will modify the prices accordingly
- If not, it will display a warning to explain that the code is invalid
Jeremy Kersten