Bug 17164 - Software error when enrolment fee or reserve fee are too high (Patron categories)
Summary: Software error when enrolment fee or reserve fee are too high (Patron categor...
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-23 02:12 UTC by Aleisha Amohia
Modified: 2017-06-12 05:00 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories (3.37 KB, patch)
2016-10-27 12:21 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 17164: Lower maximum digits of enrolmentfee and reservefee in categories (3.42 KB, patch)
2016-11-30 00:38 UTC, Mika
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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.