Improvements to product selector on discount page

[dwlhs]

Hi :)

On on of our partner's solutions, the customer reported an error, that when clicking on the Browse button to select products for a discount, nothing happened:

Further investigation revealed that this was because of an HTTP error from the requested page:

The cause for this was that a great deal of products had been added to this discount, and the ProduictId and ProductVariantId for each of these are included in the request, which is sent using GET:

HTTP limits us to sending 1024 characters per querystring parameter, and 2048 for the total length of the url. In the URL, each product is represented by it's own parameter, so the URL limitation is our problem here. In best case, each product obtains 48 characters in the URL:

&Provider.sekectedValues[0]=PROD1%7CLANG1%7CVO1

Considering only the products, in best case we would be able to add 43 products to one discount (2048 / 48). I tested this in 10.10.3, and you can actually add the number, but when clicking the Browse button, a server error occurs.

A workaround to this could be to group the products in product groups and assign discounts on group level. But on the solution in question, individual variants of a master product are associated to specific discounts, as e.g., the non popular colours of a t-shirt are assigned to a higher discount than the popular ones, so this solution would not work here. The variants could be broken up in individual masters, but then the product enrichment becomes a larger manual workload.

Another workaround is then to split the discounts in to multiple discounts with a smaller number of products. One of the discounts that had the original issues had 4500 products associated to it, and let's consider the best case scenario with 48 characters per product (not considering that the length of the counter would also increase), this would obtain 4500 X 48 = 216.000 characters. This must the be split up in the roughly 105 discounts. This is best case for one discount percentage, and then there are the other discounts percentages also to deal with. In total, there are 26.000 products associated to a discounts on this solution, so we may end up with relatively high number of discounts.

So, suggestions for improvements:

• Could this be sent using POST instead?
• Could the dialogue be opened with other parameters and resolve the selected products in a different way?

Merry Christmas and Happy New Year :)

Br.
Lars

[dwlhs]

Just a thought: Could the ProductAutoId be used instead of the primary keys? This represents the same unique record and would be able to contain a comma separated value allowing a lot more records.

[nicped]

We will remove the option to select this many products. This editor is meant to select e.g. 5-10 at a time. What you are trying to do here will cause serious performance issues and should be avoided at all costs.
Instead the products should be added to a group in commerce/pim instead and that group should be in the discount.
Coming up is another feature to create product specific discounts together with the price line in the price matrix.

I also think there is a need to discuss other ways of grouping many products for these kind of situations - e.g. "Collections" - so in a commerce shop, you can create named collections, and on the product set a checkbox to add products to a given collection - e.g. "Super duper discount" collection, and then give a discount to that collection.

So - if you in your group tree in said shop,. creates a top group called "Product collections" and under that creates what would make sense for this customer. Then they can 'Publish' the products that needs the discount to the discount collection group that is part of a discount.

[dwlhs]

With the current discounts, the frontend doesn't seem to suffer remarkable performance degradation from having many products associated to a discount, so I'm not worried about that. If we're add a maximum of 10, which the control is designed for, we'll have 450 discounts for just one percentage discount, and total we may have 2.600 discounts. I don't have experience with that number of discounts, so i wouldn't know how that will perform.

In our scenario, grouping products won't work for us with the current toolbox, because different variants have different discounts. Like here on Zalando where different colours have different discount percentages:

If we had a "Super duper discount" collection approach, the data association type would basically be the same, right? (many products in many discounts). It's the management that is different from the existing approach, and that needs to be smooth.

I'm very much on for the discount matrix, so we can manage prices and discounts for variants on a single page like in the price matrix.