If users accidentally enter a big number e.g. in Home > Patrons > Manual invoice, Koha fails with an Internal Server Error in Price.pm To reproduce, enter a value of: 99999999999999 Plack error log says: Template process failed: undef error - round() overflow. Try smaller precision or use Math::BigFloat at /home/marc/koha/Koha/Number/Price.pm line 44. After that error, the detail page of the user where the invoice was applied can no longer be displayed, it produces the same Internal Server Error This is due to the fact that the big number is stored in table accountlines. Setting to major because normal users can not recover from this situation. To recover, you have to delete or update the records in table accountlines. The same error can be produced with a manual credit. The same error can occur in Administration > Patron Categories if the numbers in the database are too big, see http://irc.koha-community.org/koha/2017-06-09#i_1942793 ...but it can not be reproduced by entering a big number. Biggest number you can enter is: 99999999
Created attachment 64171 [details] [review] Bug 18774: Add test to highlight problem with Internal Server Error in Price.pm Add a test for a big number to t/Number/Price.t Test will fail with: round() overflow. Try smaller precision or use Math::BigFloat at (...)/Koha/Number/Price.pm line 44.
Created attachment 64188 [details] [review] Bug 18774: Add test for Price.pm Add a test for a big number to t/Number/Price.t Test will fail with: round() overflow. Try smaller precision or use Math::BigFloat at (...)/Koha/Number/Price.pm line 44. Signed-off-by: Lee Jamison <ldjamison@marywood.edu> Test failure occurs as described. This patch passes QA tools. Still in need of a patch for the problem itself but the patch works as described.
How to fix? - The problem occurs at other places as well (see related bugs). A first step could be to restrict amount users can enter, similar to the situation in Administration > Patron Categories, but theoretically fines and/or credits (and budgets etc., see Bug 11698) can sum up to a value that breaks display again. Where amounts are added, the fix could be to have a JavaScript validation against the sum, but it would be a workaround only, see following comment: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11698#c2
*** This bug has been marked as a duplicate of bug 15770 ***