When attempting to update a fund, if the amount unalloccated for the fund is equal to the total, you can be prevented from saving. This is due to imprecise floating point number comparison in check_parent_total.pl
Created attachment 24900 [details] [review] Bug 11644 - Cannot update fund if total is equal to amount unallocated When attempting to update a fund, if the amount unalloccated for the fund is equal to the total, you can be prevented from saving. This is due to imprecise floating point number comparison in check_parent_total.pl Test Plan: 1) Create a fund where the amount unallocated is equal to the amount unallocated for the budget period 2) Edit the fund, attempt to change the name of the fund 3) Note you recieve an error and cannot save 4) Apply this patch 5) Repeat step 2 6) Note you can now update the fund
Tested on pasco county production server, our acquisitions team says fix worked perfectly!
Created attachment 24954 [details] [review] Bug 11644 - Cannot update fund if total is equal to amount unallocated When attempting to update a fund, if the amount unalloccated for the fund is equal to the total, you can be prevented from saving. This is due to imprecise floating point number comparison in check_parent_total.pl Test Plan: 1) Create a fund where the amount unallocated is equal to the amount unallocated for the budget period 2) Edit the fund, attempt to change the name of the fund 3) Note you recieve an error and cannot save 4) Apply this patch 5) Repeat step 2 6) Note you can now update the fund Signed-off-by: Sean McGarvey <smcgarvey@pascocountyfl.net>
I am failing to reproduce the problem, here is what I did: - My budget had 200,00 unallocated - I created a new fund with 200,00, it saved correctly - I tried editing the newly created fund, it also saved correctly Quite sure I am missing something - any hints?
(In reply to Katrin Fischer from comment #4) > I am failing to reproduce the problem, here is what I did: > - My budget had 200,00 unallocated > - I created a new fund with 200,00, it saved correctly > - I tried editing the newly created fund, it also saved correctly > > Quite sure I am missing something - any hints? I wish I had some hints to give you! I had to debug this on a production system. I tried to come up with the best way to reproduce the issue I could. It may even be that you'd be unable to reproduce the error on a different system, as this may have something to do with Perl versions. Can you at least verify the patch does not cause any regressions?
Ok, I can do regression testing, it might take a bit - busy week. If someone else beats me to it that's ok of course :)
What is the error and what was the amount used?
I found bug 11675 on testing this patch.
To re-create the bug: 1) Create a budget of 732214.84 2) Create Fund 1 of amount 651162.37 3) Create Fund 2 of amount 81052.46 Note that the sum of these amounts is 732214.83: One cent less than the budget amount of 732214.84. 4) Edit Fund 2, change the amount to 81052.47 This will generate the following warning: Form not submitted because of the following problem(s) ------------------------------------------------------------------------------------ - Fund amount exceeds period allocation
Created attachment 25348 [details] [review] Bug 11644 - Cannot update fund if total is equal to amount unallocated When attempting to update a fund, if the amount unalloccated for the fund is equal to the total, you can be prevented from saving. This is due to imprecise floating point number comparison in check_parent_total.pl Test Plan: 1) Create a fund where the amount unallocated is equal to the amount unallocated for the budget period 2) Edit the fund, attempt to change the name of the fund 3) Note you recieve an error and cannot save 4) Apply this patch 5) Repeat step 2 6) Note you can now update the fund Signed-off-by: Sean McGarvey <smcgarvey@pascocountyfl.net> Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Created attachment 25349 [details] [review] Bug 11644: (follow-up) Add a FIXME for the precision value Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
(In reply to Barton Chittenden from comment #10) > To re-create the bug: Thank you for that! I am able to reproduce the issue and confirm the patch fixes it.
Pushed to master. Thanks, Kyle! However, I have declined to push Jonathan's follow-up, and instead have pushed one of my own with the following FIXME (which to be clear, is NOT directed at Kyle's patch in particular): +# FIXME - we really need a better way to do this consistently +# and across the board, be it bigints, Math::FixedPoint, a +# modernized version of Math::Curency that isn't tied to the system +# locale, or something else. The problem with Jonathan's suggestion of using a system preference to specify the number of decimal places for a currency is that such a thing is not actually a global attribute -- it's more properly an attribute of the currency. Hard-coding the number of decimal places to 2, while not ideal, won't break things for folks who use JPY.
Pushed to 3.14.x, will be in 3.14.07
Pushed to 3.12.x will be in 3.12.13