[Spike] Estimate how much time would the "sourced variant" feature take

[RachL]

⚠️ Please use clockify code #77a Sourced variant when working on this

Context

CoopCircuits is looking for an estimate on this feature as some of their users might be interested : there are 5 big hubs which sells products from the same producers. Currently they either use inventory or duplicate the producer profiles. The number of producers is growing but so is the number of hubs. Duplicating start to becoming a cumbersome task.

Network 2.0 answer this need with 2 features: product finder and sourced variants. The purpose of this issue is to first estimate the sourced variants. Once sourced variants are available, we can work on the product finder to help hubs find producers they want to work with. In the meantime, support team will need to help link producers and distributors. The other way around is not possible: we can't start the product finder without the ability for hubs de create variants (sourced variants).

See this discourse post for the first ideations on the topic : https://community.openfoodnetwork.org/t/network-phase-1/1906/2

Potential solution

The main idea is to give ability to the distributor to create products, but only products from producers they have access to.

In more detail:

• When creating a variant, a producer or a hub will be able to link the variant to a “source”.

• to start with, distributor variants will only be created through cloning

• Each user profile will only be able to link their products to a source from whom they have a granted permission.

• a new permission need to be created

• Each time a user (owner) gives access to another user to its catalog, the user which was granted access can populate its own catalog with products from the owner. The source of these new products is set to the “original” owner. The user which was granted access won’t be able to change the source of the product.

• Some other fields might not be available for a change : unit, product category and weight (others??)

• product list shows the source: Mario's early prototype suggested a "from..." in the name + a new column. I thing it's easier to stick only to the column, as a product group can source variants from different producers. I also wonder if we need a source / variant owner, or if we could simply use the supplier / producer field

• product list can be filtered by distributors (use case: the distributors has several distributing enterprises). This filter is not showing up if no distributor has created products.

Full prototype:
https://www.figma.com/proto/zuOqI0d3H7Op9VVVyDkuRM/Network---Sourced-variants-and-OF-on-the-Go-prototypes?node-id=55-2921&viewport=-9832%2C735%2C2.3966405391693115&scaling=min-zoom

See also a documentation of all use cases:

https://docs.google.com/spreadsheets/d/18H75V9RVPstJnxluwM77gw2uR-XvflC1eOpzdRW93Hw/edit?gid=0#gid=0

Out of scope but maybe needed to create the technical solution

We need to keep in mind that hubs will use this feature to create variants to mirror the producer variant and change anything they want (name, price, stock). But they also want to be able create compound products: e.g. a basket with veggies coming from various producers.

I guess that for hubs to have the ability to compose their products from several producers, we need also the ability to attach a stock level to a group of variants, instead of the variant only. This has several use cases:

• a product available in bulk but sold in different packaging: I have 50 kg of potatoes, I don't want to guess if shoppers will first buy the 1 kg bag or the 10 kg box, I just want to create 1 variant = 1 packaging and group all these variant together with one stock value (50 kg).

• a box with several products, each having their own stock which forms the total stock of the group

I'm hoping we can start working on source variants without these features, which add complex tests scenarios.

Additional info

This solution does NOT help distributors to create different prices or stock for the same distributor variants, for different shoppers. This will require a dedicated iteration. In the meantime, variants will be duplicated and tagged accordingly.

Acceptance Criteria & Tests

1. Refresh the documentation of the technical solution
2. List all affected pages (e.g. do we need to change something on OC ? - e.g. how to differentiate between sourced variants and regular variants)
3. Estimate how many days sourced variants would need
4. Add a ballpark estimate to change the UI of the shopfront to display producers per variants and not only producers per variant groups
5. Add a ballpark estimate for inventory migration: this feature would totally retire inventory, so we would need to migrate its current users.

[tschumilas]

Some other fields might not be available for a change : unit, product category and weight (others??) - I would say that properties that were set by the originating producer should not be available for change. (ie - if a producer says their product is certified organic - this property should 'carry' with the product through the chain.)

[RachL]

Thanks @tschumilas ! I'm wondering about not allowing to change unit and weight. What if the hub wants to sell the product in a different size / packaging? 🤔 maybe we should leave it open?

[tschumilas]

I agree @RachL . Because I just thought - it could be that a hub buys a ceritifed organic product from one producer, and a non-organic product from a second producer, and combines them into a new variant. That new variant could not/should not adopt the properties associated with the source product. And if the new variant DID adopt the properities - we would need a way for the hub to decide which properties get adopted and which do not........ so - for now we should leave it open that the hub creating the new variant can change name, unit type, category, description, tax category, variant unit name, units ... etc.

[RachL]

Following a chat with @pacodelaluna the following topics need to be studied more deeply:

• Permissions: when several distributors are managing profile for producers how do we want permissions to work? do all distributors have equal right on the producers enterprises all the time?

When producer are managing their product themselves, they need to give permissions to create variants out of them but not to edit their product catalog, to avoid mistakes.

• Notifications: when a distributor is creating a variant from a producer, and some times later the producer change the label of that source variant or another field that might impact how the distributor is displaying the variant: do we want the distributor to get a notification of this change?

[tschumilas]

Here, whenever we've had several distributors managing the profile (and product catalogue) for the same producer/supplier - there have been problems. Distributors don't seem to 'share' a supplier very easily. These cases usually end with the distributor who is the producer 'owner' removing permissions for the other distributor (and we have had some nasty relations). I don't know the solution - maybe in other instances these distributors are sharing nicer than they have been doing here in Canada.