Openfoodnetwork: Confusing error messages when I create an 'on demand' product and have a blank on hand value

[sstead]

Description

If you create a product for which you have as much quantity as needed ("on demand"), it is contradictory to say that the "on hand" value is 0, so we consider that as a bug.

Expected Behavior

When I create a product and select "on demand", whatever is in "on hand" should not block the product from being saved and should transform into something consistent (like "infinity", "on demand" or [empty field] for instance).

Actual Behavior

If I'm creating a new product and clear the on hand value (from '0' to blank) and then select 'on demand' I get an error saying that the 'count on hand is not a number'. Then the system autofills the on hand value as 'Infinity', but again, this gets the error message 'count on hand is not a number'. I need to write '0' in the on hand value, and select 'on demand' for the product to be created without issues.

Steps to Reproduce

1. Go to "products", "new product"
2. Fill in everything and check "on demand" + delete 0 in "on hand"
3. Click Save

Gif

If I try to save this product....

... I get this message.....

... the user needs to figure out that they must write '0' in the on hand field, not blank, or infinity.

Context

The user was trying to create a on-demand product and was blocked, and didn't understand why it was not working.

Severity

I suggest 3 as: the bug is annoying, but doesn't prevent from using the platform (4) BUT most users are impacted (3), so I would tend more towards 3.

Your Environment

• Version used: 1.10.1
• Browser name and version: Chrome 53.0.2785.116 (64-bit)
• Operating System and version (desktop or mobile): Ubuntu 16.04 LTS

Possible Fix

• Hiding the on hand field from the UI when you choose on demand and then setting a null in the on_hand database column
• Or field remains empty and doesn't block saving
• Or field display "-" or "on demand" or "infinity" and doesn't block saving

[Matt-Yorkley]

It looks like this has been partially covered in other commits since this initial issue was created in 2015. The behaviour is quite different now; the stock value defaults to a 0 when the form loads and also when an incorrect value in entered. It could still do with a little improvement though.

[myriamboure]

@sstead I had opened a similar issue but my proposal was :
if I delete the "0 "in the "on hand" box and clic on "on demand", maybe we can force the system to reput the 0 so that it doesn't bug... if it's the easiest way ;-)
BUT More user friendly (because it can be a bit confusing to have 0 in stock and on demand at the same time) woud be to ensure that the "Infinity" doesn't create the bug, maybe remove the control on the field "on hand"? Maybe the control can be "either a number or "infinity""? (to ensure we can't enter any malware code ;-))

[daniellemoorhead]

It could still do with a little improvement though.

@Matt-Yorkley what do you think the improvements would be if what @sstead described above is no longer the case?

[myriamboure]

Or maybe if I click "on demand" the system can but a very high number like 9999 and as long as "on demand" is check the value remains 9999 ? @simoneluijckx @RachL what do you think in term of UX ?

[sauloperez]

I can confirm we also had a user complaining about this (besides ourselves) on the very first interview we did.

What about hiding the on hand field from the UI when you choose on demand and then setting a null in the on_hand database column? I'm trying to find the way these things are normally solved in terms of UX/UI.

As per my experience, things like setting 9999 are the worst you can do. They bring you lot of trouble down the road.

[myriamboure]

Sounds good @sauloperez, seems pretty user friendly to hide and have an empty field (is that what you mean with "null"?) in the product table ! If someone from your side want to move forward on that please feel free to pick-it up, else maybe @ltrls can work on it ? Feel free to comment on the tech proposal Pierre ;-)

[enricostano]

Keep in mind that is possbile that this has been already fixed in Spree 2.0.

Was introduced here https://github.com/spree/spree/pull/2080

[sauloperez]

Agree @enricostano. We should first evaluate what happens in Spree 2.0 and then decide whether it's worth spending any effort on it while we reach 2.0.

[simoneluijckx]

@myriamboure I agree with the confusion the nr. 0 can create when clicking 'on demand' and I think 9999 will be just as confusing... No number showing would be ideal or something like ' - ' .
But will wait for Spree 2.0 for now.

[sigmundpetersen]

Should we wait for v2 for this @sauloperez @luisramos0? Should we set as blocked and open up space for other bugs in Dev Ready?

[luisramos0]

this is already fixed in v2 actually. you can mark as blocked or just close it. or test it in staging FR (I just did that myself) and close it afterwards.

[sigmundpetersen]

If you have verified that this is working in v2 on fr-staging, let's close it.
Anyone that disagrees please reopen.