We define "quantity" as a decimal(10, 2) column, which means the biggest value it can accept is 99 999 999.99 (8 digits on the left, 2 on the right).
However, commerce_line_item_handler_field_edit_quantity currently does this:

'#maxlength' => max(4, strlen($quantity)),

instead of this:

'#maxlength' => max(4, 8),

so maxlength gets set to 9 (probably because it's not rounded before the length measurement, didn't check), allowing you to input a value that crashes the update (overflow on the quantity field).

However, even with setting maxlength to a smaller value, there's still the possibility of overflowing the amount column of the price field.
That is something we can't really fix, since we don't know how big the prices can be.
Still, it's something to have in mind.

So, I should submit the maxlength change as a patch, and you guys should tell me if you have any additional ideas, so that the user can't crash the site through basic input.


amateescu’s picture

Priority: Minor » Normal

The easiest solution would be to change the total amount field to a bigint. There's a small catch though, because it is a price field and that would mean changing every price field to a bigint. Maybe we need a new field type for totals?

That would allow us to store numbers like:
99 999 999.99 [decimal(10, 2)] x 2 147 483 647 [signed int] =
214 748 364 678 525 163.53, which is smaller than
9 223 372 036 854 775 807 [signed bigint].

@bojanz, max(4, 8)? Seriously? :P

amateescu’s picture

Title: Line item quantity views field has a maxlenght that is too big » Line item quantity views field has a maxlenght that is too big [no patch]
Status: Active » Needs review

Hrm, scratch that, I should've compared

21 474 836 467 852 516 353 to
 9 223 372 036 854 775 807.

So, we must also change the quantity field to decimal(9,2).

rszrama’s picture

Issue summary: View changes
Issue tags: +sprint