Openfoodnetwork: "Use supplier's 'on demand'" is not represented in the inventory page

[kristinalim]

"Use supplier's 'on demand'" is not represented in the inventory page.

Description

A variant override may have any of these three values for "on demand":

1. nil - Use the supplier's setting
2. true - Override the supplier's setting with true
3. false - Override the supplier's setting with false

After an inventory item has been added:

1. Creating the variant override without clicking the "on demand" checkbox, e.g. by setting the price, creates the variant override with a nil setting. This is displayed as an unticked checkbox.
2. Ticking the checkbox sets this to true.
3. Unticking the checkbox sets this to false.

There are two problems here:

1. There is no way to tell between nil and false - both are represented by an unticked checkbox.
2. There is no way to go back to nil.

Expected Behavior

1. User should be able to know if the setting is nil or false.
2. User should be able to go back to nil.

Actual Behavior

User cannot.

Steps to Reproduce

Signed in as producer:

1. Create a product.
2. Set the variant to have 0 count on hand, and save.
3. Set the variant to be "on demand", and save. (Step 3 should no longer be relevant after this, but it is. A different issue will be created for this bug, but meanwhile we want to take advantage of it for testing.)
4. Grant distributor permission "to add to order cycle" and "to add products to inventory".

Signed in as the distributor:

1. Add a payment method and a shipping method to the distributor.
2. In "Inventory Settings", enable this: "New products must be added to my inventory before they can be put into my shopfront".
3. Add the variant to the inventory:
   a. Go to Products > Inventory.
   b. Click "Review Now" to see the list of products that can be added.
   c. Click "Add" for the variant.
4. Create an ongoing order cycle, and include the variant.
5. With inventory item but no variant override:
   a. Go to Products > Inventory.
   b. Notice that the "on demand" checkbox is unticked.
   c. Go to the shop page. The variant would appear.
6. With variant override but nil "on demand" - Using: supplier setting of "on demand" (true)
   a. Go to Products > Inventory.
   b. Override the price for the variant, and save.
   c. The variant appears in the shop.
7. With true "on demand" - Using: VO setting of "on demand" (true)
   a. Go to Products > Inventory.
   b. Tick the "on demand" checkbox, and save.
   e. The variant appears in the shop.
8. With false "on demand" - Using: VO setting of "on demand" (false), supplier setting of "count on hand" (0)
   a. Go to Products > Inventory.
   b. Untick the "on demand" checkbox, and save.
   e. The variant does not appear in the shop.

This demonstrates that the unticked checkbox in 5 and 7 are different. And, there is no way to go back to scenario 5.

Context

Related to https://github.com/openfoodfoundation/openfoodnetwork/issues/3058.

Severity

bug-s2

Possible Fix

We could have the checkbox to a SELECT field with three options:

1. nil - "Use producer setting"
2. true - "On Demand"
3. false - "Limited Stock"

[luisramos0]

I thought we could make this more simple and say it can never be nil, ie., hub cannot use the producer setting? But I believe it's a valid feature we shouldnt kill: hub wants to use producer on_demand setting (use farmers stock config) but still override the price for example.

[kristinalim]

@luisramos0 Yes, I think it's a valid and used feature. For example, the variant in #3058 was supposed to have nil "on demand".

[myriamboure]

Of course we need to keep the nil option, it's the most use, mostly people will override price but not stock producer info.
I guess the value by default will be nil, by default the inventory use producer setting. So the dropdown menu will not even have the "select" option and then has to choose, by default it's on nil and then you can change if you want.
Given Slack discussion on bug channel, we need to move that forward as today, the workaround implies that if in today the producer says in its catalog there is no more product, as we have forced "on demand" in inventory product will remain in shop... with pretty bad consequences for the hub commercial activity.
So we keep this one as s2 bug.

[myriamboure]

As a reminder after we have done this one we need to check if ok not to move forward on https://github.com/openfoodfoundation/openfoodnetwork/issues/3067 and https://github.com/openfoodfoundation/openfoodnetwork/issues/3068 for now. The three issues were related to bug #3058

[kristinalim]

Yes, I think we can leave #3067 and #3068 for later. Thanks for updating the tags of those issues, @myriamboure.

[kristinalim]

After the initial review of PR #3104, I realized we don't need to add more terms to our vocabulary. Instead of the original proposal to use "Use producer settings", "On demand", and "Limited stock", how about we just use:

• (Blank) - Meaning, _default_ behaviour, which is to use producer settings
• Yes
• No

We already have the "On Demand" column heading to let us know what this field is about.

@myriamboure @luisramos0 @Matt-Yorkley

[luisramos0]

my favorite option would not include a blank entry (could be misleading for the user). I'd have 3 options: "Use producer settings", "Yes", and "No"

[Matt-Yorkley]

I think "Use producer settings" is much nicer than a blank option.

[kristinalim]

Thanks! "Use producer settings", "Yes", and "No" look nice together. :slightly_smiling_face: I'll update the PR.

[myriamboure]

For info the original issue has happened again on our user who has 15 shops, some products appear in no shop, we have to fix manually by going in each of the 15 inventories and forcing on demand... hope we can fix that quickly, it is very unstable...

[myriamboure]

@kristinalim @Matt-Yorkley the work that Kristina is doing on this is probably impacting product import... the values to put in csv to import in producer catalog or inventory (especially inventory) might change for on demand column for instance. We need to remember that and probably open a separate issue to take it into account as soon as this fix is ready.