Quantity limitations on category level

[uwe_h]

Hi Jan,
I have a feature request (at least I think it is not possible at the moment) regarding the quantity limitations. So far, you can set min, max values and select a value X, so that only multiples of X are valid per product. Would it be possible to have the same possibilities on category level? I have a customer with this need because of package requirements. I am not sure if using a base product would be a good solution... In my case, the product comes in different flavours which all should be shown as separate product with separate price and image in front-end, but as a second attribute I need the size which should be a radio-box option. From what I have seen so far, this is not possible with attributes in Phoca Cart?

Thanks for any advice!

Best Regards,
Hannes

[christine]

Hi Jan,

FYI: it's the same. See here please: https://forum.joomla.de/thread/10149-ec ... ellmengen/
Christine

[Jan]

Hi, yes, for now it is possible per product. This means, you e.g. e.g. only order 6x bottles of wine (6 or 12 or 18 or ...)

The question is, if this will be done on higher level, how to solve conflict between product rule or higher level rule.

The next question is, should it be related to category or to whole order?

Jan

[uwe_h]

Hi, yes, for now it is possible per product. This means, you e.g. e.g. only order 6x bottles of wine (6 or 12 or 18 or ...)

The question is, if this will be done on higher level, how to solve conflict between product rule or higher level rule. :idea:

The next question is, should it be related to category or to whole order?

Jan

Hi Jan,
thanks for coming back to me. Your two examples are pretty clear to me:
1. Product rule is more specific and should therefore have a higher priority than the higher-level rule.
2. Imo it would be beneficial to have it on category level rather than regarding the whole order. Why? These restrictions will usually apply to a certain kind of products, you already mentioned wine bottles, but that doesn't necessarily mean that the shop only sells products of this kind. It does make sense to restrict the wine bottle order because of package sizes, but if a customer wants to add small accessories like a bottle openener to his wine order, it shouldn't count towards the limit. It would be more flexible having the restrictions on category level.

[Jan]

The problem with categories is, you can have product with more than one category. So in such case it can comes to conflicts And even of course the performance can be much more slower because now it just counts the items of one product, counting it for categories means loading all categories for each product in calculation which slows down the calculation resulting

Jan

[uwe_h]

The problem with categories is, you can have product with more than one category.

Hmmm, okay, I didn't know that but I see how that could be useful in some cases. Perhaps it would make sense to designate one of the category as main category which is taken into account for quantity calculations with the other categories ignored?
Regarding performance issues: I suppose most users will opt to use either product limitations OR category limitations, not a combination of both. So when the user approaches the checkout-page, I would iterate through all categories, sum up the respective number of products category-wise in the cart to see if the category-level criteria is met and then (if there are any product limitations) check them individually (i.e. product-wise) afterwards, like you probably did it up until now.

I just found your account on GitHub, can you show me the file where you make the check at the moment?

[Jan]

Hi, it is not so easy, if there is a parameter for something, it just needs to be counted even the parameter is not disabled. To limit something, you need to have data, amount of items. So it not just about the limit at the end but about a calculation where you need to count the items by different criterias (like for now you count items or items with attributes, so in this case you need to add information about categories and count of categories base too)

The calculation is here:
https://github.com/PhocaCz/PhocaCart/bl ... lation.php
counting limits for cart:
https://github.com/PhocaCz/PhocaCart/bl ... t/cart.php
for order:
https://github.com/PhocaCz/PhocaCart/bl ... /order.php
https://github.com/PhocaCz/PhocaCart/bl ... lation.php

... etc.

The calculation works with only the category which was active when adding the item to the cart. And the problem is, when you add the same item from Category A, it is stored with Category A, when you add it from Category B, then both are stored with last added category:



Because there is of course not difference when one product was added by category A, and then by category B because it is just in cart 2x. So the information which is there:

- product in cart 2x Product A
- product in cart belongs to Category A, Category B
- product in cart was added by Category B as last

So if one product belongs to two or more categories the validation is ambiguous

- if it was added from Category B as last with 6 pieces, it is valid for category B
- but it is not valid for Category A even in fact it should be even valid

So the way could be to get all categories of each product in calculation and store such information. But in this case, the calculation will slow down because of selecting all categories for each product, so the performance can be much more slower

Jan

[uwe_h]

Hi,
thanks for the detailed explanation, knowing how the implementation works the category is probably not really suited for this purpose. It may not be the most elegant solution, but one could introduce a new abstraction level "quantity restriction group" and make that an optional property for every product. Then during calculation you wouldn't need to iterate through all of the product's categories. But I get this would be quite a big change to Phoca Cart and it may not be obvious to all users what the purpose of this new product group is. What's your view on that?

[Jan]

The problem is that having it on product level is the fastest and easiest way to do it. As it is just value in product row so you don't need any additional tables or rules, etc. Everything else will mean some new database table with specific relation, some new calculation logic, etc. so this can slow down the performance and make the administration/managing more confusing.

Another procedure to think can be some batch adding of this rule to all products so it will be easy to add it and it will stay still on product level which is the easiest and fastest to work with such kind of feature

Jan

[uwe_h]

I agree it could be confusing and/or difficult to maintain but you can't really solve this task without introducing some new relations between products, right? How could a rule on product level take into account the number of other products?