Decimal quantity breaks checkout: "Quantity is not a valid number."

Looking into it.

I was able to replicate the problem. IMO the check should be made based on whether the product has fraction quantity allowed or not. I will check how Commerce core does it OR what it has.

Some work came up.

In a vanialla Commerce installation you can find the decimal setting for quantity here admin/commerce/config/order-item-types/default/edit/form-display/add_to_cart. Change the quantity widget to Quantity and you will see the decimal setting.

I believe we can do something similar in the POS.

Agree, we should match the what Commerce does for the cart.

Patch attached. This matches what Commerce core is doing.

#6 patch sets the quantity field by default to accept integer values but does not work when you check the option to allow decimal values i.e decimal values are rounded up.

Thanks Fred, I'll look into that, also need to fix the failing tests.

Rerolled the patch and updated the schema, also updated the tests to remove the decimals from the quantities.

Fixed missing schema, turns out bool != boolean. Test passes locally now.

Few todos:

• Should we default the allow decimal option to true for existing setups, so that it doesn't change there functionality?
• We should have at least 1 test that tests a decimal quantity setting, to confirm that option works
• Why do we set the max to 9999? i know most of our users will probably be less than that, but it seems like an unnecessary limit, maybe I'm selling 10,000 $0.05 washers or something.

This patch just adds a test for the decimal setting and fixes a small typo, decimals don't seem to be returned properly in the form however and has to be investigated - might have something to do with how it's being rounded in src/Plugin/Field/FieldWidget/PosOrderItemWidget.php L270-276 (or so).

• Removed quantity limit.
• Changed defaults to allow decimals to two places.
• Added input for number of decimal places in input.
• Rewrote some of the logic for calculating the returned quantity.
• Rewrote test to account for new defaults.
• Removed changes to other tests with new default.

Passing locally, although Firefox seems to round the x.00 decimals to x, despite both the value and step, which is a bit weird UX wise (Chrome renders this fine).

Fail related to #2986424: Refactor Tests

rerolled now that #2986424: Refactor Tests has landed

When I disabled decimals, I was still able to input decimal quantities. Also, I would update your tests to use something like 1.50 and 1.5453 to test the right number of decimals and confirm that things are working, as 1 and 1.00 are the same and won't show a flaw well

Updated the test to insert and test decimal values in the quantity field. I'm not sure if there's a way to completely restrict an HTML number input from having decimals input, but at the very least we can reject it properly.

Removed round() when decimals are enabled and reverted to previous method.

This still isn't working right for me, although I didn't see anything obviously wrong in the code

If i try and set to 3 digits, it can get stuck not letting me user the up/down arrows of the number field, if i input a number manually, it rounds it to 2 decimal places even though I asked for 3. The step is set right, but the validation seems broken.

Also, and this is possibly not even worth fixing, but if I have decimals disable and set it to like .2 it will remove my product, because it rounds down to 0. This is pretty edge case, but it is also unexpected behaviour to the user.

So because Commerce rounds the order item quantity itself we can't really be as flexible as we'd like (e.g precise weight), instead for the quantity field we match what Commerce does for the cart page (which actually doesn't seem to be working for me). If we wanted to enable things like precise weight we'd probably need to implement another field to order_item. Also updated test to check that step is set correctly.

Really need to remember to remove debugging screenshots... fixed.