The quantity values are now only restricted to whole values
function views_form_validate($form, &$form_state) {
$field_name = $this->options['id'];
foreach (element_children($form[$field_name]) as $row_id) {
// Ensure the quantity is actually a numeric value.
$line_item_id = $form[$field_name][$row_id]['#line_item_id'];
if (!is_numeric($form_state['values'][$field_name][$row_id]) || $form_state['values'][$field_name][$row_id] < 0) {
form_set_error($field_name . '][' . $row_id, t('You must specify a positive number for the quantity'));
}
// If the custom data type attribute of the quantity element is integer,
// ensure we only accept whole number values.
if ($form[$field_name][$row_id]['#datatype'] == 'integer' &&
(int) $form_state['values'][$field_name][$row_id] != $form_state['values'][$field_name][$row_id]) {
form_set_error($field_name . '][' . $row_id, t('You must specify a whole number for the quantity.'));
}
}
}
Why is this restricted to whole numbers and not to decimals, floats or doubles (or something similar)??
The articles in my webshop are not expressed in a number of items but in a number of size (which is most likely not a whole number). If i comment the line
//form_set_error($field_name . '][' . $row_id, t('You must specify a whole number for the quantity.'));
Than i can use doubles.. So what's the reason behind this check?
Comments
Comment #1
rszrama commentedIt's just a default behavior. There's no particular place in the UI to add a setting to change this, but other threads in the issue queue demonstrate how to alter the validation on quantity widgets to support decimal values. They aren't full floats, as I believe we only allow a precision of 2 or 3 on the quantity column in the database. In any event, search the issue queue for issues pertaining to quantity and you'll find the past discussions. You may need to include closed issues in your search, but there may be one or two open issues, too.
Comment #2
Anonymous (not verified) commentedOk so i fixed the issue by setting the datatype to decimal (non integer) and removed the round from default value, like
Maybe it's a good idea (feature request) to unlock the field (admin/commerce/config/line-items/product/fields) and let site admins choose a different widget for the quantity field ??
duplicate from issue: http://drupal.org/node/1071682
Comment #3
rszrama commentedHmm, you know, I didn't think about the fact that this quantity widget was coming from a Views field handler now. We never had a place for the settings before, but inside the field handler we do. Big "duh" on my part. Reopened. : )
I believe we'd also need to update the settings for Add to Cart form display formatters to allow specifying a decimal quantity instead of just a hidden vs. visible quantity widget.
Comment #4
amateescu commentedRelated issue: #1379084: Line item quantity views field has a maxlength that is too big
Comment #5
Anonymous (not verified) commentedi've created a temporary patch.
But as i mentioned before, the (my) problem lies in the fact that quantity entries are not always whole numbers but decimals that can be used for
* size (length, width, height)
* weight
* volumes
The API of the commerce core gives the possibility of creating new currencies with custom format, and these formats are checked in some places. Maybe a similar system (API) is a good idea for quantities, with for example pre- and post-fixes (like meters, yards, lbs, etc...)
Comment #6
Anonymous (not verified) commenteddifferent integer checks also removed
Comment #8
Anonymous (not verified) commentedComment #9
Anonymous (not verified) commentedComment #10
rszrama commentedThis patch doesn't really address the problem, just hides it. The fix for this will entail adding an option to the handler for the quantity edit field on the View and then taking the setting of the field into consideration in validation. We still need to set an error if an invalid value is given for the type of quantity validation selected.
Comment #11
5n00py commentedHi all!
I create patch that define field setting for enable decimal values.
Comment #12
5n00py commentedAlso we need another feature request for prefix-suffix options for this field.
Comment #13
vasikei tried the #11 patch and, indeed, it let me use Decimal for the views.
But, what about the Add to cart form for the Product display entities.
here is a patch that includes a solution for the Add to cart formatter.
However, I am not sure about having this settings for every "formatter, or it's better to have a unique setting for the quantity type that it's allowed, but i don't know where it should be, product entity, product reference, line item .....
Comment #14
5n00py commentedSure, I forgot the Add to cart formatter ))))
Some thoughts about the settings:
1. There is no reason to store this setting per formatter cos each formatter use same product reference
2. Can be useful having deferent settings for each product type
3. product reference field can store products of any defined product type(based on field settings)
So i think it would be nice to have per product type setting and per reference (default it can dynamically inherit setting from product type).
With this model we can have few use cases:
1. One product type and few displays/references
2. Few product type with one display/product_reference
Each variant can handle situation with different(by count system) products.
Now if we accept this idea I have a question: How to handle this in views?
PS: patch from the #13 comment satisfies me completely )))
Comment #15
rszrama commentedUnfortunately, in the 1.x branch we can't change the function definition to add a new parameter in the middle of other parameters. That means we would either need the $quantity_type parameter to be last or to make it part of the line item itself somehow. I think it may be best to make the quantity type part of the line item data array for one compelling reason: theoretically, I should be able to take a line item and reproduce its Add to Cart form without requiring any additional information. As it stands, though, I would have no way of knowing if the form should use integer or decimal quantity validation since that option came in separately through whatever function called the form builder.
The good thing, of course, is that putting this in the $line_item data array means we can go ahead and make this change in the 1.x branch, because it won't change the actual function definition any more. : )
Comment #16
vasikethanks for your training comment.
definitely, you deserve the right patch
ps: about validation, i think it's already there
first: positive numeric value check
second: integer if it's integer
Comment #17
5n00py commentedGood work Vasike!
But I have a little question.
How I can use different quantity type for different products? What is the best way to do this?
Comment #18
rszrama commentedFor that we'd need to extend this feature out to the product type definition or something.
Comment #19
vasike@5n00py: with this approach, it will work only if you have distinct product displays for the products types (this option it's product display based).
@rszrama: this was exactly what i asked/suggested (see #13), but i am not sure anymore.
Comment #20
PatchRanger commentedIt is already done in separate module : see Commerce Decimal Quantities.
This module allows to let or restrict decimals in quantity by product type.
Comment #21
firflant#8: allow_decimal_quantity-1393536-7.patch queued for re-testing.
Comment #22
chris matthews commentedThe 7 year old patch in #17 does not apply to the latest commerce 7.x-1.x-dev and (if still relevant) needs to be rerolled.