Product list block not displaying products with variants

[mlocati]

Let's assume we want to sell a t-shirt with 3 different sizes: S, M, L.

Since the stock is specific to the size, the t-shirt has a "Size" variant, and the stock quantity should be defined at the "size" level, for example:

• I have 1 t-shirt with size S
• I have 2 t-shirt with size M
• I have 3 t-shirt with size L

(I haven't specified that I have 6 t-shirts in total, since it's useless).

The problem is that the Product List block doesn't list the t-shirt.

I checked the code, and I saw that the SQL query that's being executed is

SELECT
    p.pID
FROM
    CommunityStoreProducts p
    INNER JOIN CommunityStoreProductGroups g ON p.pID = g.pID AND g.gID in (3)
    LEFT JOIN CommunityStoreProductSearchIndexAttributes csi ON p.pID = csi.pID
WHERE 
    (pQty > 0 OR pQtyUnlim = 1)
    AND (pActive = 1)
GROUP BY
    p.pID, p.pName, p.pPrice, p.pActive, p.pDateAdded
HAVING
    COUNT(g.gID) = 1
ORDER BY
    pName ASC
LIMIT 1000

So, the t-shirt isn't listed because its quantity (pQty) is empty, but as I wrote above, I don't think that counting the total number of t-shirts makes sense.

Am I missing something?

[Mesuva]

The idea is that you still need to set a quantity of the base product to something, so either a large number or unlimited. There are some cases where you might have limits on some of the selections, but not on all.

[mlocati]

Thanks for the lightning fast reply, Ryan! You are a super-hero!

BTW I don't think it's correct to set the "total number of t-shirts" as unlimited (or to a large number): if I sell all the 6 t-shirts in the 3 sizes, the product shouldn't be listed anymore...

[Mesuva]

Going back a step, setting the total quantity to 6, matching your total, isn't really useless here. Setting it to 6 will make the product disappear when sold out (if that's what you configure on the block). Setting it higher or unlimited, will make it continue to show, but with no options selectable, often people want that for products with lots of options, as the stock may change frequently.

[mlocati]

Having to manually handle the total number of t-shirts would be a nightmare... every time we add a new variant, or change the quantity of a variant, we'd have to count all the variants and manually update the total number...

[Mesuva]

That's why you can set it to unlimited, and let the individual variations quantities restrict what can be ordered. And if you know you've completely run out of t-shirts and truely want to hide a product, you can do that at the product level when needed.

[mlocati]

Great, thanks!

[mlocati]

Setting it higher or unlimited, will make it continue to show, but with no options selectable, often people want that for products with lots of options, as the stock may change frequently.

I still think that there's something wrong...

IMHO CommunityStore should handle quantities in variations exactly like it does for quantities of products without variations (that is, we should have the option to automatically hide out-of-stock products). Also, users shouldn't care about the quantity of the products whose quantities are defined at the variations level.

So, here's what I'd like (and ready to implement if it's ok) for products with variations...

First of all, users can't view/edit the quanttities at the product level (CommunityStoreProducts.pQty and CommunityStoreProducts.pQtyUnlim) , but only at the variations level (CommunityStoreProductVariations.pvQty and CommunityStoreProductVariations.pvQtyUnlim).

Those two fields are updated automatically;

• CommunityStoreProducts.pQty is automatically set to the sum of the CommunityStoreProductVariations.pvQty values
• CommunityStoreProducts.pQtyUnlim is set to true if at least one of the CommunityStoreProductVariations.pvQtyUnlim is true, to false otherwise

The above operations can be performed whenever something changes at the CommunityStoreProducts and/or CommunityStoreProductVariations level (that is, for example when saving products in the dashboard/store/products dashboard page and when an order is submitted).

If the data in the two tables is updated via Doctrine ORM only, this can be easily done by using a Doctrine ORM event subscriber, with something like this:

• In the the main package controller.php file

  public function on_start()
  {
     $subscriber = $this->app->make(CommunityStoreEntityEventsSubscriber::class);
     $entityManager = $this->app->make(EntityManagerInterface::class);
     $entityManager->getEventManager()->addEventSubscriber($subscriber);
  }

• In a new CommunityStoreEntityEventsSubscriber class, we subscribe to the prePersist / preUpdate / preRemove events of Doctrine\ORM\Events (or just the preFlush event?). In that event listeners, we automatically update the pQty and pQtyUnlim fields of the Product entity.

For consistency, I'd also implement:

1. an easy way to update the pQty/pQtyUnlim fields for a specific entity
2. an easy way to update the pQty/pQtyUnlim fields for all the entities
3. add a CLI command to do 1 or 2
4. add a Task (ConcreteCMS v9+) and a Job (concrete5 v8) to automatically fix all the Product entities

If you prefer, I can of course make all the above an optional opt-in feature.