edwinljacobs
commented
4 years ago Hi,
I assume you mean https://github.com/EmicoEcommerce/Magento2TweakwiseExport/blob/e3d940ba6f6d35f305686e79f409d4adf459ce12/src/Model/CombinedStock/Bundle.php#L21
What we are trying to do here is select all option groups for a bundle and determine for each group if there is an option (i.e. product) in that group that is in stock. If for all option groups there exists at least one product that is in stock then that option group is marked in stock, you can see that at https://github.com/EmicoEcommerce/Magento2TweakwiseExport/blob/e3d940ba6f6d35f305686e79f409d4adf459ce12/src/Model/CombinedStock/Bundle.php#L30
In the case of sample data (bin/magento sampledata:deploy) we can find an example (product id 51, name: "Sprite Yoga Companion Kit"). I dont know if you have a sample data installation but I use that for some of my test data.
This product has 8 children (in my case) and each of those children belong to one of 4 option groups
So for all groups we max is_in_stock to assign is_in_stock for that group and then we min over these group status to get the final stock status, so that if any of the groups do not have a product in stock then the bundle is not in stock. Here we also consider the stock status of the product. That is the goal.
You are problably thinking why not use something like the stock registry as you pointed out or some other interface implementation that will just give you the stock for the bundle? The reason for that is that the stock registry executes the following: 1)
/**
* @param \Magento\CatalogInventory\Api\StockStatusCriteriaInterface $criteria
* @return \Magento\CatalogInventory\Api\Data\StockStatusCollectionInterface
*/
public function getList(\Magento\CatalogInventory\Api\StockStatusCriteriaInterface $criteria)
{
$queryBuilder = $this->queryBuilderFactory->create();
$queryBuilder->setCriteria($criteria);
$queryBuilder->setResource($this->resource);
$query = $queryBuilder->create();
$collection = $this->stockStatusCollectionFactory->create(['query' => $query]);
return $collection;
}So a getList query Then the afterGetStockStatusPlugin triggers:
/**
* @param StockRegistryInterface $subject
* @param StockStatusInterface $stockStatus
* @param int $productId
* @param int $scopeId
* @return StockStatusInterface
* @SuppressWarnings(PHPMD.UnusedFormalParameter)
*/
public function afterGetStockStatus(
StockRegistryInterface $subject,
StockStatusInterface $stockStatus,
$productId,
$scopeId = null
): StockStatusInterface {
$websiteCode = null === $scopeId
? $this->storeManager->getWebsite()->getCode()
: $this->storeManager->getWebsite($scopeId)->getCode();
$stockId = $this->stockResolver->execute(SalesChannelInterface::TYPE_WEBSITE, $websiteCode)->getStockId();
$sku = $this->getSkusByProductIds->execute([$productId])[$productId];
$status = (int)$this->isProductSalable->execute($sku, $stockId);
try {
$qty = $this->getProductSalableQty->execute($sku, $stockId);
} catch (InputException $e) {
$qty = 0;
}
$stockStatus->setStockStatus($status);
$stockStatus->setQty($qty);
return $stockStatus;
}This code triggers about a million database queries (this is obviously exaggerated), this is not an issue per se for a small catalog and a limited amount of stores. However we must facilitate for 10+ stores and 50000+ products per store. The code you presented is 75 times slower (on my machine) then the current situation and for a large catalog this is simply not an option. This is exactly the reason why the export module is written this way. I would love to just use magento's interfaces for this but I cant as it is way to slow. This does mean we have to know a lot of the internals and this is error prone, trust me I am well aware of that.
I could take a look into the code to see if there are errors with it but there is a reason why we don't use the normal magento interfaces and their implementations.
If your catalog is not too big by all means make a preference for the class in your own module and simply ask the stock registry for stock status and be done with it. I could add method "getStoreId" to the export entity class so that you can ask the correct store id from the exportEntity if that helps. But the general approach to data retrieval will not change. That being said, if there is something wrong with the bundle implementation as is then it should be fixed, if there are any, feel free to point them out :) If you have cases where the code breaks then I could take a look at a stripped version of your database if this is an option, or describe to me exactly what I need to do to reproduce your situation.
I hope this explains a bit about why the module is written the way it is. I have a quality of life update planned for the module, a lot of the properties are private, this will change soon so that whoever implements the module can override, plugin or do whatever to change the behaviour without having to deal with all kinds of private access modifiers.
With kind regards
maxserv-woostelbos
Issue Brief
Hi,
I've tested the new method that checks if a bundled product 'is in stock' and should be added to the export. As far as i can see a bundled product is added to the xml when one of the simple products has $qty. Shouldn't a bundle product only be 'in Stock' if all of the simples are aswell?
If tested a bundle product and i think this would be sufficient for: 'Model/CombinedStock/Bundle.php'
Environment
Steps to reproduce
Run console command: 'bin/magento tweakwise:export'
Actual result
Bundled products that are not in stock are still added to the export file
Expected result
If one of the simple products of a bundled product is 'Out of stock', the bundled product is out of stock aswell.