-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable product where variations are disabled on website/store view appears as salable. #3296
Comments
Hi @ioweb-gr. Thank you for your report. Please, add a comment to assign the issue:
|
After further investigating I notice that on the stock index for the specific store view, the configurable product's total salable quantity is incorrectly counted. It appears as Could you point me to the code responsible for building the index of the total salable quantity of the configurable products to debug it? |
I ended up tracking it all the way to this function
Which results in the following SQL in my case
Which seems to calculate the total quantity available of the product in the required sources but fails to take into account the store view and the simple product (child of configurable in this case) status in the store view. If the focus here is just to mark the salable quantity and then filter it out somewhere else I'm not sure where this would happen. However it seems that the isSalable function will look in the inventory_stock_X tables and if the product is salable it will appear in the lists even though it shouldn't. The end result on inventory_stock table is this one But since
|
Looking up at Configurable product indexer the query is
Yielding the result as above and again skipping the fact that the offending products have disabled status
|
This seems related to #2413 |
I don't think this issue will ever get worked on. This is because a Stock in MSI is shared between different sales channel - and product status is a website scoped attribute. I have had to bring the logic for filtering out configurable products with disabled (but saleable) children when building. the query for PLP |
Several years later we also see this exact bug. We managed to create a query that finds the problematic products. SELECT
stock.sku,
stock.quantity,
parent_products.quantity,
stock.is_salable,
parent_products.is_salable
FROM
inventory_stock_1 AS stock
LEFT JOIN
(
SELECT `parent_product_entity`.`sku`, SUM(stock.quantity) AS `quantity`, MAX(stock.is_salable) AS `is_salable`
FROM `inventory_stock_1` AS `stock`
INNER JOIN `catalog_product_entity` AS `product_entity` ON product_entity.sku = stock.sku
INNER JOIN `catalog_product_super_link` AS `parent_link` ON parent_link.product_id = product_entity.entity_id
INNER JOIN `catalog_product_entity` AS `parent_product_entity`
ON parent_product_entity.entity_id = parent_link.parent_id
GROUP BY `parent_product_entity`.`sku`
) AS parent_products
ON
parent_products.sku = stock.sku
WHERE
parent_products.is_salable = 0 AND stock.is_salable=1 |
Preconditions (*)
Steps to reproduce (*)
Expected result (*)
Actual result (*)
e.g.
in category
in product
The text was updated successfully, but these errors were encountered: