Add Support for multiple stores & clean up locations store relationship

I posted this in the child issue #2838050: Add further possibilities to filter stock locations available for stock allocation, but it is relevant here because the two issues are so intertwined, at least conceptually and architecturally.

Re-posting here:

OK, It's been a few months, and I haven't worked on it recently, but I'm posting my Work in Progress (WIP) PR -- https://github.com/BBGuy/commerce_stock/pull/35/files -- which addresses at least initially most, if not all, of the issues touched on in this issue.

1. config/schema/commerce_stock.schema.yml - stock service configurations are sets of stock services with weights, and filters for entity types, order types, stores, locations, etc. This way stock services (here plugins) can be instantiated multiple times, in a list of configured services, where business logic can loop through and find availability and transaction locations.
2. src/Resolver/ChainStockServiceResolver.php - stock services are resolved at runtime for a given entity, context and quantity.
3. src/StockAvailabilityChecker.php - stock availability is checked through 'getAvailabilityLocations' method we identified as needing attention in this issue.
4. src/StockServiceConfig.php (deleted) - stock service configuration is no longer a static object, it is a set of stock service plugins paired with properties for determining at runtime the correct service for a given entity, context, and quantity.
5. src/StockServiceManager.php - stock service manager is no longer just a static list of services but the entrypoint for getting stock services at runtime.
6. Each stock service implements one or more interfaces related to the types of transactions supported
7. Each stock service, when instantiated in a stock service configuration, can be configured to support the available transaction(s) for each case (again, based on criteria in the stock service configuration, e.g. store, customer, order or product type)

I may have forgotten a few notes, but those are the big ones. It still needs more work to finish, but this is the direction I've headed and would love to discuss / get help on. I probably won't be able to work on this for at least another few months. If anyone would like to discuss, please find me on #commerce in drupal.slack.com or in the issue queue here.

Tagging. This is blocking #2613264: Drupal 8 port of Commerce Stock. And bumping priority because of that.

Ive reviewed both, figured 35 needs a reroll anyway and indeed too much in one PR. Do like it more then the other one but until the reason for the change is clear cant disagree. Lets create soms separate (followup) issues for the major things from the PR we really want / need.

The commit 'fac45ca ' is throws an exception when the current store is not set because in '$store_to_use->id()' $store_to_use is null.

So this patch fixes the issue.

Forgot the patch.

I had to think about this a bit more and i have some questions / comments:

1. Should a stock location always have a store id set ?
2. Should 'commerce_stock_location's be able to work without 'commerce_store' ? (other entity types)
3. Can an order exist without setting a store id?
4. Can an order be create by default without an existing store? (out of the box)
5. Can person at source X select target stock location at ...? (or should that occur at the target store)

What i think / what i've found:

1. I believe it should. Any stock transaction occurs at a location, that's the store i believe.
2. I believe it should not and should always use a store. The code that runs when the fields exist actually use store code, so can't depend on non-commerce_store entities.
3. Yes, but for sure not by default and prolly needs a custom order type + neat overrides to commerce core to pull it off. (users are forced to create a store before creating an order for the default order type).
4. Nope. On regular commerce installs (if not all) a commerce_store entity exists (at least one). (relevant for out-of-the-box)
5. Long story short: A person should select the target store and not be aware of the stock locations at that store. The process that runs on the target should assign a stock location when receiving the stock (if none exists yet or multiple exist).

I believe by now that with most code already (possibly) depending on the store entity it should be changed to always use a store. I propose to add a new property on the stock location that holds the store_id for that stock location, remove the available stock location fields on the store and add a 'store' select widget when creating / editing a stock location.

I got like 55 more lines of reasoning, including things like: access to stock locations depending on store, building UI's to transfer / list stock, transferring stock (and what to select), creating stock movement reports per store and more, but let's see about this first, might be enough to expose what i think could use some more work.

I figured you would say something like this :)

like a warehouse or a repair center

Exactly why i asked. In my mind any stock location needs a store first. Not to sell products, but to have a location.

The commerce_store module might have been named commerce_location (cause that's how i look at it). A store of type 'warehouse' is very common in my setup, even stock location that's reserved at the manufacturer is a stock location + store of type manufacturer in my system.

And then permissions. The person moving stock might not even be able to view the stock location on the target side, while they can select the store. (and i wonder if they should be able to view the stock location on the target side anyway, but that's more from a process perspective, because moving stock now requires only an action on the source, while the target should be responsible for selecting the final stock location where the goods will be stored when receiving the stock. The source now selects where the product will be stored on the target, feels odd, not their responsibility).

No sour grapes, it's a choice and implementing as i propose might be done in a new independent module, just think we might debate this a bit, so it's clear for everybody how and why. For a simple webshop with only a single group of administrators the current implementation will work fine, but i wonder about more complex systems. I (for example) (with the current system) would need to limit the list of stock locations people can use in some way and everything is attached to a 'store', users, permissions for related entities, etc, except stock. So now i would need to implement something on top of stock and store to hook these 2 up. With the locations attached to a store this is totally different story.

When working with remote stock locations this might become a problem (i see why this choice is made), but stores are about to get a status field (with a bit of luck). And a different store type already offers a way to add per-type stock location settings (for remote stock api's etc).

See #2921000: Add a status field (enabled/disabled) to stores for the store status issue.

Understood and agreed.

Simpele use case of why:

Create 25 stores with each 5 stock locations with the exact same name. Think people might not be amused with the current UI. Plus more stock locations only makes this worse. No way to group them logically. And prolly sorted by id or name.

Again i understand why the choice is made, so lets continue.

A store in commerce is a billing location. https://drupalcommerce.org/blog/42419/commerce-2x-stories-stores

So a stock location is not a 1:1 relationship to store. Imagine two stores - a french one and a german one. Two warehouses - one for the french shop and one for the german shop and a repairshop that repairs items from both stores. As you cannot sell products / place orders without a store, each location belongs to at least one store, but can belong to multiple stores. I didn't see, how a stock location can't belong to a store. It's a many2many relationship.

Any functionality that's blocking custom development will have high priority to go in and I will do my best to follow how the module is used and any common patterns will be candidate for changes/future versions.

So we should dig out pr35. I feel this will give us, most if not all of the extension points we need. It uses the plugin system and the resolver pattern. Commerce core is using this all over the place, so it's good for DX too. I will see if I can get steve back on this - at least to get us started again.

I think we can close this one and handle the individual issues.