Bug 17164

Summary: Software error when enrolment fee or reserve fee are too high (Patron categories)
Product: Koha Reporter: Aleisha Amohia <aleisha>
Component: System AdministrationAssignee: Lari Taskula <lari.taskula>
Status: RESOLVED DUPLICATE QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: gmcharlt, jonathan.druart, lari.taskula
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15770
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11698
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18774
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories
Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories

Description Aleisha Amohia 2016-08-23 02:12:54 UTC
For some reason I had ridiculously high enrolment fee and reserve fee data causing a software error when trying to access Patron Categories

Software error: Template process failed: undef error - round() overflow. Try smaller precision or use Math::BigFloat at /home/vagrant/kohaclone/Koha/Number/Price.pm line 44.
My enrolment fee was set at 8866609962973970000000.00 and my reserve fee was set at 3862694923528880000000.00

Obviously it's very unlikely for a librarian to set the enrolment fee or reserve fee to be this high but if it happens accidentally, it breaks the system and causes this error. Perhaps there should be some kind of constraint when entering this, like a maximum reserve fee constraint etc.?
Comment 1 Lari Taskula 2016-10-27 11:52:49 UTC
I noticed the same issue in my test database. For me the high fees are probably caused by test builder setting some random huge number. It works after lowering the fees.
Comment 2 Lari Taskula 2016-10-27 12:21:45 UTC
Created attachment 56915 [details] [review]
Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories

If the values are too high, Patron Categories page will crash with:

Software error: Template process failed: undef error - round() overflow. Try
smaller precision or use Math::BigFloat at
/home/vagrant/kohaclone/Koha/Number/Price.pm line 44.

This is likely caused by test builder setting random huge numbers when creating
categories.

I found out that 19 digits is the maximum that can be handled. Surely it is
enough for both enrolmentfee and reservefee. This patch lowers the maximum
number of significant digits in order to avoid this crash.

To test:
1. Set category enrolmentfee with a high value, like 3862694923528880000000.0000
2. Go to cgi-bin/koha/admin/categories.pl
3. Observe Software error
4. Apply patch and run updatedatabase.pl
5. Reload the page
6. Observe that software error is gone
Comment 3 Mika 2016-11-30 00:38:38 UTC
Created attachment 57815 [details] [review]
Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories

If the values are too high, Patron Categories page will crash with:

Software error: Template process failed: undef error - round() overflow. Try
smaller precision or use Math::BigFloat at
/home/vagrant/kohaclone/Koha/Number/Price.pm line 44.

This is likely caused by test builder setting random huge numbers when creating
categories.

I found out that 19 digits is the maximum that can be handled. Surely it is
enough for both enrolmentfee and reservefee. This patch lowers the maximum
number of significant digits in order to avoid this crash.

To test:
1. Set category enrolmentfee with a high value, like 3862694923528880000000.0000
2. Go to cgi-bin/koha/admin/categories.pl
3. Observe Software error
4. Apply patch and run updatedatabase.pl
5. Reload the page
6. Observe that software error is gone

Signed-off-by: Mika Smith <mikasmith@catalyst.net.nz>
Comment 4 Jonathan Druart 2016-12-13 12:15:16 UTC
We use 28,6 for almost all the price fields, I think we should stick with it.
Have a look at bug 15770 and bug 11698.

Note that the tests should be executed in a transaction and these random data should not persist in DB.
If it happens, we need to fix the tests, which are the root of the problem.
Comment 5 Jonathan Druart 2018-06-06 17:37:45 UTC
Fixed by bug 15770.

*** This bug has been marked as a duplicate of bug 15770 ***