We had a good detailed discussion about next steps for Product Refactor and how to take it forward towards 'Retiring Inventory / Variant Overrides; while gathered in Aus in May 23. Notes below.
We can progress Part 1 independently. It needs to happen before any further network or release of Product API v1 can happen.
Part 2 probably shouldn’t start until we are clear on Part 3. Design work on Part 3 could commence now? or following Product tagging? (@Rachel@lin_d_hop@Mario TBD)
1. Simple Product Model - Merge Products & Variants into one Model
Merge Products & Variants into one
Add family/set/group so that ‘variants’ of the same Product can be ‘grouped’
. . maybe as outlined here
Update Products API v0
NB. We will need agreed process for giving notice of changes to API v0 (agreed it will be in release notes … but someway to give people a chance to make sure they’re looking - post release notes also to API channel if API changes included?)
2. Create Linked Products (LPs)
(Note: Calling it Linked Products instead of Chained Products, to avoid any sense of 1-to-1 from each Product link. Each product may be linked to many parents and children . . once part 5 is complete).
Add Parent field to Product
Replace Variant Override with 1st generation product
‘Permission to create Variant Override’ becomes ‘Permission to Create Copy’
Keep logic of Variant overrides re. stock and price i.e. if a Child Product has Stock or Price of NULL, use Stock or Price of parent product
3. UX/UI - Transition Variant Overrides (VOs) to manage new Chained Products (CPs)
Will retire Inventory page, aim to handle all within Catalogue page
How much UX/UI for handling chained products already exists? Maybe some but needs big revisit
Will need some kind of drop-down for handling the key classes e.g. ‘my own products’ ‘my copies’ ‘hidden’? etc . . some core functions that should exist outside of voluntary tagging (@lin_d_hop@maikel I didn’t write a decent note on this - if either of you can remember more clearly what we thought was on the drop-down please update)
UX consideration - can we make the ‘chain’ visible / functional - so that I can see the linked stock and prices?
At some point there will need to be data migration from VOs to CPs
NB. We want to keep the ability to add a Product (permission manage) without creating own copy. We also want to KEEP the permission to add a product to order cycle as is, without taking your own copy, so that we don’t lose the ability to just draw from the same stock. We are replacing variant overrides, not removing product sharing permissions
NB. This will have big implications through Reports, Bulk Products, Order Cycle Settings . . we will want to simplify where we can - particularly in Order Cycle settings
4. Transformations
Allow for management of changed products i.e. increase the number of fields that can be edited when creating the copy - change Units; descriptions etc TBC which fields we open up at different times
Allow for automation of ‘transformation’ rules e.g. I want my copy of this product to have 10x the stock of the parent product (because I am splitting it into 10 packets), of 1.10x the price because I’m adding a 10% mark-up etc - needs thinking about what transformations we will support
Transformations will need to consider affect how stock and price changes flow through the network
5. From 1 Copy to Chained Copies
Allow me to make a copy of a copy
Make a product that has multiple parents
Add multiple children to a parent (?)
There was some discussion as to whether 4 or 5 should come first, but both are adequately far away that we felt we could reconsider closer to the time
I would say let’s get new admin colors on the way and then start design on part 3? Unless we feel we can do the 2 in parallel.
I think the most tricky part in the retirement of inventory will be how we want to handle prices. Stock being already handled in part 2 if I follow everything. So we will need to find something big enough it can help us inventory but also something small enough we don’t end up needing to work on our Offer model here already.
Chat in product circle, some other considerations:
Transition is going to be very tricky. We think we are going to need to run the two systems in parallel for a while, because we can’t just move everyone all at once
Back-office Uplift needs to go out alone - everyone will get this (soon)
We will then do product list tagging . .
We will need to run both systems in parallel - we can’t find a way to avoid this How can we reduce this pain?
IF we can do Part 1 above BEFORE the product list tagging that would save refactoring - TBC depending on people availability
Then we identify different categories of users and use feature toggle to roll this out
Those who are NOT using Inventory: we turn on the product list tagging and turn off inventory
Then we identify specific users and work out the transition plan. Some might be manual, some might have a migration
Possible we could/should have a working Inventory API endpoint, so that we can easily pull up the lists and info of where inventory is used for easy analysis and transition
Then the only one that is left is group buy . . discussion . . it is possible that this can stay where it is because the ‘Product’ is becoming the ‘Product Group’ that associates a group of products. But we think this will still be a problem because now the variants can have different units, so the way the group buy works won’t work anymore. Should we consider retiring this feature? How much is it used? Will it be replaced by ‘transformations’ in Network 2.0, which will work better with the new unit sizes etc. @Rachel@tschumilas are you able to do an exploration of how widely this is used so that we can decide if we can retire it? (in Aus, in last year, 8 enterprises sold 174 products in 1,000 transactions, so probably retiring would be hard / bad, @maikel further investigating implications in Aus)
either way, for now we will NOT do the work to move it or remove it - awaiting further info
NB. The original Product model (now Product Group) will still contain the product name, description and image, so these fields still need to be inherited from the base product. While it would make things better / simpler to have these on the same model, if we put Description and Image on the Variant we would need to do significant work on the shopfront (and likely elsewhere).
For now to make the shopfront work, the Product Group (former Product) is still mandatory and always present for every Product (former Variant). This is necessary because it provides the Name, Description and Image fields
To get where we want to go with Linked Products and Network 2.0, we WILL need to move the name, description and image onto the Product (former Variant). AND this will require changes to the shopfront (and probably elsewhere).
We will eventually change the data structure names from Product->Product Group and Variant->Product, but not yet
On the basis of this, once the unit size is in (tomorrow . . ) this phase of Product Refactor is DONE and this line of work will next move to Product Tagging
SELECT COUNT(*) AS "count_all", "enterprises"."name" AS "enterprises_name" FROM "spree_line_items" INNER JOIN "spree_orders" "order" ON "order"."id" = "spree_line_items"."order_id" INNER JOIN "enterprises" ON "enterprises"."id" = "order"."distributor_id" INNER JOIN "spree_variants" ON "spree_variants"."id" = "spree_line_items"."variant_id" INNER JOIN "spree_variants" "variants_spree_line_items_join" ON "variants_spree_line_items_join"."id" = "spree_line_items"."variant_id" INNER JOIN "spree_products" "product" ON "product"."id" = "variants_spree_line_items_join"."product_id" WHERE "order"."completed_at" >= '2023-08-14 05:31:23' AND "product"."group_buy" = true GROUP BY "enterprises"."name";
UK:
count_all | enterprises_name
-----------+-----------------------------------
8 | Peninsula Food Market
17 | Bwyd Dyfi Hub
1 | Ljubicica
6 | User Guide Demo Hub
3 | Cambridge Food Hub
23 | In My Back Yard C.I.C.
2 | Ash & Elm Horticulture
15 | Tamar Valley Food Hub
3 | Scottish Flower Grower Collective
1 | Good Food Loop
(10 rows)
AU:
count_all | enterprises_name
-----------+-----------------------------------------------
2 | EAT LOCAL - EAT WILD North East Victoria
12 | Merri Food Hub
4 | Midlands Hub | Tasmanian Produce Collective
3 | Northern Hub | Tasmanian Produce Collective
7 | North West Hub | Tasmanian Produce Collective
9 | Southern Hub | Tasmanian Produce Collective
1504 | Westies Dry Goods Buying Group
(7 rows)
FR:
count_all | enterprises_name
-----------+--------------------------------------------
266 | AGAPES
15 | Auberge du Bernin
78 | Boule de Gum
556 | Cadajoux Bio
324 | Chl'Achuchon
56 | Connexion paysanne
4 | CORSEN
10 | DEPANDEVI
11 | GA Camille et Nicolas
4 | GAEC STE ROSE
493 | GapsAB Clisson
8 | Groupement d'achat de Feins
40 | Groupement d'achat des Gavroches Utopistes
59 | Groupement d'achats de Montreuil sur Ille
179 | Groupement d'achats du Piotaix
1 | Groupement d'achats Pays de Gex
853 | La Coursière
501 | La Termitière
37 | Le Tour du Bocal
1 | Utopies&co
(20 rows)
So I don’t think that we can easily retire this feature.
inventory but also something small enough we don’t end up needing to work on our Offer model here already.
How can we reduce this pain?