Product and ShopProduct in a real world
#1275
Comments
|
I think having something like this would require that after product create fields should be uneditable and the updates for products would go through marketplace-admin through requests/tasks. We already discussed this with @Pikkupomo here and agree there is something we need to do for this. |
|
@suutari-ai do you have any thoughts regarding this? |
|
My thoughts. I agree to move all attributes to In Marketplace mode, there is no reason to share product information, IMO, like in Amazon or even eBay. The merchant just create an account and create their products. All the shipping and payment methods should be provided by the system through the superuser or something. In multi-stores we can have two scenarios:
If the point is to avoid duplicating data, the end result is bad as @Pikkupomo mentioned. We can make things faster when creating products like creating products from template as base or presets, then we could have some separated model which one can create this template and things are just copied (not referenced, as that could bring more complexity). Nowadays, data is cheap and duplicating info in this kind of level shouldn't be a problem for the rare use cases. |
|
Originally multi-shop features were not designed for this kind of use cases where Shops are managed by distinct people/companies. The point was to allow serving several "sites" (i.e. shops) to the same product catalog where the products share same stocks. For this kind of use case, there is a real need for the shared Serving multiple separately managed shops from the same Shuup instance is totally different use case. For that case where the shops don't co-operate, there is no point in sharing the Product instances between the shops. I think this could still be easily done with the current architecture. Shop A can create their coca-cola which has Product P-COKE-A and ShopProduct SP-COKE-A and shop B creates P-COKE-B and SP-COKE-B. Only problem here is if they want to use same SKUs for their Cokes. That could probably be solved by just making the SKU field non-unique in Product table and add the constraint to ShopProduct's Shop-SKU pair. It could be a setting if the shops are co-operative or not and that would then determine if duplicate SKUs are be allowed in Product table or not. |
|
@suutari-ai so, if we remove the uniqueness of SKU and modify supplier modules to calculate stocks from SKU instead of product id, do you see any possible issue? If reason for that is just the stocks, so maybe the SKU is the right info to pass to supplier. |
|
Why would you pass just the SKU to supplier? IMHO Product is more appropriate, especially in a setup where you have two different Products with the same SKU, i.e. when shop A has a Product with SKU "COKE" and shop B has a different product with SKU "COKE", then there is no way to distinguish them from each other just by the SKU (but through Product instance or id it is easy, of course). |
|
... and if those products in shop A and B with SKU "COKE" are sharing the same stocks, then they really should be using the same Product instance anyway, since they are the same product. I can't think of any situation where two shops (managed by the same or different companies) would share the stocks but can't co-operatively decide on the details of the product catalog they have stored in their common warehouse. |
|
Hum, well, I though in SKU because it could contain all these info to distinguish one product from another (https://en.wikipedia.org/wiki/Stock_keeping_unit) |
|
Here's my vision on how to implement this: There should be a setting which kind of multi-shop configuration the Shuup instance is using, i.e. centrally managed shops (by the same vendor) or separately managed shops (by different vendors).
These rules cannot be forced on the table level, so they must be implemented in the |
|
We need to add option for projects with either 'centrally-managed' or 'separately-managed' products. Now we offer 'centrally-managed' products. And this is somewhat related to these. Which is now only used by API and we need to decide whether to actually fix this thing and offer admin edit+actually use these at front. @suutari-ai what is your thoughts about those shop product names and descriptions? Mainly because I think I am removing those instead of fixing the admin, front and themes.
|
I like this idea and I think it's better than my idea of having this as a per installation configuration option. It could even be extended to use cases like these:
|
I'm not sure about this. If there is no shop specific names and descriptions then a shop administrator wouldn't be able to change those details for a shared product (see [d] in my last comment). Though it could also be a good thing, since then the General Administrators would be more in control and they could still allow editing of those details by unsharing the product (see [g]). So maybe I'm leaning towards removal of those from the ShopProduct. |
|
@suutari-ai @tulimaki And what about other models? Like Attributes, ProductTypes, Manufacturers, etc.. we have being adding
IMO maybe we just add a |
Seems like a good idea to me.
Having just a single nullable FK to shop feels simpler to me and IMHO would be better. |
|
In progress. We are going pretty much the suggestion @suutari-ai made in Jul 5. |
|
I started working on this some time ago https://github.com/shuup/shuup/compare/master...Pikkupomo:shopproduct-tuning?expand=1 |
Background
If my memory serves me well, the original ideology behind
ProductandShopProductwas to allow so-called "Base Products" to be available in a single Shuup installation in a multi-store environment. TheseProduct's would then provide unchangeable data for all the merchants to use whereas theShopProductjust defines the price and other, store-by-store changing, information.Real world
In a real-world situation, this setup will bring nothing to the table it only adds complexity to the implementations. It also slows down our implementations as we do constant queries back and forth between
ProductandShopProduct.I give you an example of an environment where this won't work at all:
I have a multi-store environment, where I sell Coca-Cola bottles, who is the one who decides how big the bottle is, what is the SKU etc.
I think you all are already starting to see a problem with this implementation
In a real world situation, the merchant should have power over the product information they sell, all of it. I would also point out that having a implementation like this (
ProductandShopProductseparated) causes developers to build mediocre solutions to their projects when trying to go around this issue.Solution
Even though this was built multi-stores in mind, it seems it's a flawed solution and relies too much into sunny cases. So, preparing to Shuup 2.0 release, I suggest we move all the fields from
ShopProducttoProductand removeShopProductaltogether.Thoughts?
The text was updated successfully, but these errors were encountered: