Impossible to get sellable bundles with MSI in 2.3.4?
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 357
- Forks
- 262
- PR merge metrics
- No merged PRs in 30d
Description
This is a question as much as a "bug" report - it's likely this is all a consequence of the transitional status of MSI
UPDATED FOR CLARITY and new information
-
What tag/version of Inventory do I need to have installed on a 2.3.4 installation to have the most consistent bundle behaviour?
-
What are the real constraints for a bundle to be sellable if MSI is on, on both the bundle and its components?
The documentation says that MSI shipment selection does not yet support bundle and implies that the solution for now is to have bundles be NOT stock managed. But that is not quite right, or not anymore.
-
my old bundles (migrated via data migration tool) show on the site, (some don't, but thats sku changes i think). All show out of stock until I make a lot of contorsions with the component products such as putting them in default stock. That didnt use to be the case. These bundles that show as "out of stock" on the website are totally fine being sold in admin. No stock warning. I thought stock_status=1 in the "old" cataloginventory tables was all that was needed, but clearly some extra conditions apply. What are they?
-
new bundles created do NOT show on the site at all. They are correctly in stock though and can be sold fine from admin - but not on the site. Noticed: my migrated bundles were put in the source stock tables for the default source by the migration. New bundles do not get put in. Should they be?
First, a "non stock managed" bundle will still appear out of stock if any of its components are not fully "in stock" in the (not in use) default source. It works until one of the products gets out of stock, and then it cannot be put back in stock without putting every product in the default source and with back order enabled.
Every table I look it up in has a status of 1 for sellable for the bundle and all its components, for every source including the default one, but still the bundle is not sellable on the front end.
I am pretty sure stock status to 1 was all that was supposed to be needed and there might be issues on my site or my data, but I cannot be sure because there is no documention of what should be - what tables, what data, in what state is a "correctly working" bundle?
It's really unclear what the current "normal behaviour" should be, and the documentation and tickets I have found do not match the reality. Knowing what should be would go a long way to know whether I have bugs or have wrong understanding or expectations.
What settings does a simple product, bundle, grouped product etc need to have to succesfully be sellable on site with MSI.
Even for simple products it is not just having sources allocated with stock of it.
What master tables should a product appear with which flags to show as sellable - I think it is both cataloginventory_stock_item and inventory_source_item which feed their respective indexes, is that even right? any other?
I thought inventory_source_item should be pushing changes to cataloginventory_stock_item but no, the link is not there or not complete
Indexes for the sites are:
cataloginventory_stock_status
cataloginventory_stock_status_replica (i have a cataloginventory_stock_status_idx but it is always empty?)
the view inventory_stock_1
inventory_stock_2 etc. if more stocks
is that correct?
My experience so far on this one live site
-
some actions seem to put quantity in the default stock - numbers keep appearing there even any stock import I do is with clear source set. Can I assume this is an artifact of the transitional status, or is it a buggy module? or do I need to write cleanup scripts?
-
being "out of stock" in the default source, or having it unassigned, does not mean that a product is not buyable on the site. BUT it will mean any bundle containing it will be out of stock on the sites, no matter what the site stock says. That bundle will be status 1 on the stock indexes and still not be buyable.
-
the new "Stock Status" field does not appear on simple product edit forms but it often stays on "out of stock" even though everything is in stock. This seems to be based on the cataloginventory_stock_status . This will cause the same issue as above regarding shipping or bundles. It has to be set to "in stock" manually, only way to do it is programmatically or 1 by 1 using the "bulk edit" tool. Is this normal or an artifact of data migration?
-
new bundles created are not showable on the website because entries are not created in inventory_source_item - the bundles that show all have 2 rows in inventory_source_item one for the default source and one for the preferred source as configured for shipping. I have tried putting the bundle in stock management and out of it, making it in/out of stock - no action in the admin has yet resulted in getting these rows created.
My best guess is that this is linked to scope confusion or there's something missing
Clearly there is a fragility there and there is a reliance on products being in a particular status in the default stock even if other stocks are used. There should be a small bit of documentation about it? because then we can manage it rather than be baffled
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the named MSI data sources and indexes: inventory_source_item, cataloginventory_stock_item, cataloginventory_stock_status, inventory_stock_1, and inventory_stock_2. Document the expected flags, source rows, index state, and bundle constraints for sellability, including which behavior is supported in version 2.3.4.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- backend, databases, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100