Cart item quantity

Please see #1035180: Setting quantity to a very high number induce errors

Oooh, interesting. The previous issue chose a maximum quantity of 99999999 that we figured would be sufficiently high, but perhaps we left it too high. The error here is actually that the amount is too high for that column. The variables we can address here are:

1. Lower the maximum quantity on the cart form. 99999999 is a little much. : D
2. Increase the size of the amount column for prices.

I guess we may as well just lower the quantity further, but that won't help if the product price is $10,000,000. : P

Tagging

How about fractional quantities?

For hourly service rates, 0.5 kg of peanut butter.. etc.

Or does the existing quantity method have to be completely disabled to accomplish this?

Fractional quantities are currently supported to two decimal places in the database, but the form by default validates them to be integers. This is being mediated through a custom property of the quantity box's form element called #datatype. We initialize it to integer, but if you remove it or set it to something else, the integer validation won't happen. You could set it to decimal but you'd need to ensure that you don't accept fractional quantities to a greater precision than the database can handle.

So the setting is either integer or decimal?

In setting as a decimal for 0.5 kg of peanut butter (mass, length etc.), there'd be risk of someone ordering 1.4 coconuts?

You could only alter the quantity form field of the form for the types/categories you want.

Do you mean by altering the field type and widget at admin/commerce/config/line-items/product/fields ?

Quantity is hard-coded.

Yeah, the only recognized setting right now for #datatype is integer. If you change it to something else, you can check for it in a custom validate handler. So you could set it to a custom decimal string and then provide a validate handler for the quantity element that ensures it's a multiple of .5. You'd have to do this all custom through hook_form_alter(), though - there is no UI for this.

I'm going to commit the change that has been live on the demo for a while but slightly improved. The cart form and order edit form now default the maxlength of the quantity field to 4 but will grow it if the current quantity is larger so quantities aren't hosed.

It looks like there's still a bit of work to do on this one as setting quantity can cause a PDO exception / fatal error.

Steps to reproduce.

1. Set quantity to 4 digits in cart, update order
2. Set quantity to new maxlength ( 7? ) , update order
3. Set quantity to new maxlength ( 10? ), update order
4. Fatal error

MESSAGE	PDOException: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'quantity' at row 1: UPDATE {commerce_line_item} SET order_id=:db_update_placeholder_0, type=:db_update_placeholder_1, line_item_label=:db_update_placeholder_2, quantity=:db_update_placeholder_3, created=:db_update_placeholder_4, changed=:db_update_placeholder_5, data=:db_update_placeholder_6 WHERE (line_item_id = :db_condition_placeholder_0) ; 

Looks like it needs some additional validation to ensure the final quantity isn't outside the range that can be stored in the database field.

DT

Just a temporary form_alter workaround I use for this, in case useful, another way would be to add a custom validate hook.

This snippet lets you choose a global maxlength for quantity and enforces it on the cart form.

<?php
/**
 * hook_form_FORMID_alter
**/
function mymodule_form_views_form_commerce_cart_form_default_alter(&$form){
  if( isset( $form['edit_quantity'] ) ){
    foreach( $form['edit_quantity'] as $key => $value ){
      // Enforce quantity maxlength
      $form['edit_quantity'][$key]['#maxlength'] =  variable_get('mymodule_quantity_maxlength', 4);
    }
  } 
}
?>

cheers,

DT

P.S Awesome module set by the way, really nicely done and taking shape well.

Good thoughts on a solution for this, but ultimately if someone is altering a form, they're responsible for the consequences. For example, you could alter away the SKU textfield on the product form and break things just as badly. I raised the idea in another issue on deleting default fields breaking Views that maybe we need a documentation place where we can say "alter this at your own risk" and outline why. That would be a good enough solution from my standpoint.

Thanks rszrama, though a final validation to make sure the 10 digit quantity doesn't break the db field constraint at some point would be good, I'm ok with altering the form for now.
cheers,
DT