Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
- Product attributes can now have custom values.
These values are specified by the user during the SO creation.
They are also available on the webshop frontend.
- Product attributes can be configured to create variants "on demand".
This means that product.templates having these attributes will only create product.product variant
when that combination is actually selected in a sale order/in the web shop.
Product attribute values are also improved to handle extra prices and exclusions
in all three modes ("never", "dynamic, "always")
Specification
=============
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
5. Create variants on demand
- add a new mode to generate variants as they are added to the order/cart
(needed for big # of combinations managed in the inventory and/or produced in mrp with specific boms)
- replace the boolean by a selection radio
tooltip for this new field:
Always:
Variants are generated straight away when
the attribute values are combined in the product configuration.
Only when the product is added to a sales order:
Variants are generated once the combination is selected in the sales order.
This is advised when variants are customized on demand and manufactured as such in Odoo.
Never:
Advised when variants are not needed in Odoo.
The selected values just show up in the description of sales order lines.
- ability to define attribute extra prices & exclude combinations in all variant modes
- if at least one attribute of the product in set to "on demand" mode, generate all the variants "on demand"
67c3de295e9 wrongly adapt coupon to multi-websites as website references should
have been written in website_sale_coupon and not sale_coupon.
Closes#2673
This commit adds the `website.multi.mixin` to coupon program to make it
multi-websites.
It also adds the website_id field in the views and adapt SQL constraint on code
which now became multi-websites friendly.
Since commit 006ce9c887 set the `Promo Code` view active (customize_show),
the `shop_sale_coupon` JS tour should not be working anymore.
But it was working since this change introduced a race condition that was
luckily making the test to succeed (most of the time).
(This bug appeared weeks ago on nightly build)
Basically, the tour flow was:
1. Activating `Promo Code` in customize option -> Cause a page refresh
2. Waiting for the DOM to contains the promo code input (shown after page
refresh performed by step 1.)
3. Typing a promo code and submitting it
4. Waiting for the discount line to appear (after page load performed by
step 3 form submit.)
This test was working fine as the promo code customize option was disabled.
Thus, the promo code input would only be visible after the refresh of step 1.
It would always wait for the refresh to occur before continuing.
No race condition possible.
Since the change of 006ce9c887 that activated that view by default:
- The promo code input would already be on the DOM when the tour was executed
- Clicking on the customize option would actually disable it.
Then, since the input was already in the DOM, the step 2 would instantly
continue without waiting for the refresh of step 1 and step 3 would be
performed while step 1 would still be refreshing the page.
You would then land sometimes on the refresh of step 1, sometimes on the
refresh of step 3, depending of the test speed (and so the runbot).
In case you landed on refresh of step 1, step 4 would never find the discount
line.
---- SOLUTION ----
Click on the customize option only if not already enabled.
(The customize step could have simply been removed as it is now activated by
default. But this is better to prevent the test to fail in case we change that
customize active state in the future or to simply run the test more than once)
avoid race condition when refresh of /shop finish after the search click.
Now we start on the search page directly, that make tour faster and that
don't remove any usefull test, since the purpose of this test is to test
coupon and not the search view already tested by others tests.
Time has come to update a bit applications name, summary and website links.
Purpose is to have a website page correctly set for applications to be used
in conjunction with the newly-introduced discover button.
Names and summaries are updated to be more updated and shiny.
This commit is related to task ID 47179 and 1861544. Related PR are #1834
and #2365. First one is about classic applications while second one is about
website applications.
Co-Authored-By: Nimesh Jethva <nje@odoo.com>
* Update demo data sheet for barcode
* Modify product "Book: Office Renovation for Dummies:
- Name: "eBook: Office Renovation for Dummies"
- Image:
- Internal category: All/Services/Saleable
* Tips internal reference
* Product 10.0 % Discount =
- Name : "10.0% discount on total amount" (no space between 0 and %)
- Internal reference : 10PERCENTDISC
* Free product - large cabinet
- Should be a stockable
- in category All/Saleable/Office Furniture
- Name : Free Gift - Pencil Holder
- Picture
* Desk Customizable :
- Change its website sequence (should be displayed first in the shop)
* https://github.com/odoo/odoo/pull/25263
* Need to clean attributes and attribute values and attribute categories :
- Attributes, keep : Brand, Color, Dimensions, Legs, Weight
- Attribute Category : Rename Storage into "Material"
* Events
- Suppress Functional Webinar and Technical Training
* PoS Categories :
- Suppress
- Create PoS Category : Desks (put desks in it)
- Create PoS Category : Chairs (put chairs in it)
- Create PoS Category : Miscellaneous (and put all other products in it)
* Products available in PoS
- Remove : Air Flight, Car Travel Expense, Bpost domestic bpack 24h pro, Bpost World Express Pro, Customer Care, DHL USA Delivery, DHL USA -> International, Deposit, Expenses, Fdex International, Fedexs US, Hotel Accomodation, Restaurant Expenses,
* Product:
https://drive.google.com/a/odoo.com/file/d/1KjxcB88aDfe8qAzIpFlkBmMj5ekA9eIf/view?usp=drivesdk
Timesheet : description to update https://docs.google.com/spreadsheets/d/1nB8l8pFcRXRFnudgDJVyZZp3McaHNovlyvY0jE1ZZ54/edit?usp=sharing
* Project : less projects, more tasks
Remove "Internal - GAP Analysis", "Internal Projects"
Rename Support into After-Sales Services
Task to rename: Data import + Doc ==> Office planning
Move the task Internal Training from "Support" to "Office Design"
* AGR Project : add the following tasks and link it to the right SO line
Decoration : SO Line ==> Senior Architect
Planning : SO Line ==> Senior Architect
Furniture SO Line ==> Senior Architect
Furniture Delivery : not linked to an SO line
* Marketing Automation
Partnership offer ==> to rename into "Commercial prospection"
Steps to rename:
Offer free trial ==> Offer free catalog
After 7 days (if not yet partners) ==> After 7 days (if not yet customers)
Message for sale person ==> keep the same
* Mass mailings:
http://nimb.ws/zrKsZ9http://nimb.ws/CbNpwd
* Events:
Suppress Functional Webinar and Technical Training
Tracks to update : https://docs.google.com/spreadsheets/d/1sKkJrltXY3Gz7ue3mVysZxaWGybKpx5fIhgUBnhbNDs/edit?usp=sharing
* Helpdesk
Rename team into Customer Care
Create 2 tickets in default team
Urgent : Kitchen collapsing (assigned to admin) : link to the task SO053: [SERV_585189] Customer Care (Prepaid Hours)
No pririoty : Where can I download a catalog ? (not assigned). Ticket type = question
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
Commit a42c27f99e0061b7c4f recently fixed some bugs on sale_coupon.
This commit add some tests to be sure theses bugs are fixed and won't appear
again.
This closes#1744
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, a reward line in cart would have the same qty field/spinner
than regular line even if the field is readonly and the spinner qty disabled.
Now, as for a linked line (eg: optionnal product warranty), simply show the
qty without qty spinner and input.
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
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
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.
Aurélien Warnon