[SPIKE] Fees/fines refactoring estimation
Description
Environment
Potential Workaround
blocks
defines
Checklist
hideTestRail: Results
Activity
Holly Mistlebauer July 8, 2020 at 8:03 PM
I wasn't quite sure what to do with this issue, but it looks like has been updated with this estimate...
Front End Estimate: Large < 10 days
Back End Estimate: XXL < 30 days
...which has gone into the Capacity Pan so we are all set.
I have created a JIRA to deal with the naming of things. I am remembering now that UNAM supplied the "account" label. What helped me remember is that I found a note where I asked them to change several user facing places where 'fee/fine account' was used. I didn't know why they used this terminology. It wasn't in the user story. I believe is was just a language thing. Obviously the backend wasn't changed.
Darcy Branchini June 9, 2020 at 5:05 PM
Yes, , the design and estimation. , you mentioned a few days ago that you received quite a bit of feedback on this. Are we ready to close this ticket and estimate the feature ()?
Holly Mistlebauer June 9, 2020 at 12:23 AM
This is the estimate only, correct? In other words, nothing to test...
Darcy Branchini June 1, 2020 at 2:19 PM
The "account" language is odd, but I'll leave it up to whether or not we want to tackle that too. I think our bigger issue/worry to address is that currently calculations for fee/fine on the frontend are problematic and insecure.
Marc Johnson June 1, 2020 at 11:22 AM
I've also heard that there are discussions about mod-circulation refactoring? It would be nice to change it in both modules then.
I'm keen for mod-circulation to protect itself from the oddities of the language and design used in the current implementation of mod-feefines. I don't know enough about the plans for both teams to know when either of these changes is likely to happen.
Details
Details
Assignee
Alexander KurashReporter
Alexander KurashPriority
TBD
Summary of the known issues:
Calculations on FE
Initially fee/fine actions were implemented in such a way that all calculations are happening on FE while BE acts as a simple CRUD service for storing results of these calculations. Not only this approach is an anti-pattern, it is also not safe and, considering we're talking about financial data, poses a significant risk. Anyone who can use Postman or Fiddler can write anything he or she wants to the DB (provided they have access to the platform).
Bugs
While working on has found a bug on the fee/fine details page that allows, among other things, to overpay a fine by any amount. It is a bug in the UI architecture that leads to account data not being updated on the screen after PUT request to the server. Account state will remain the same as it was when the user has loaded the page. No matter what actions you'll do, the system will allow you. But when you reload the page you'll see that the client was charged hundreds of dollars instead of ten.
Double vs. BigDecimal
In February we created a technical debt ticket https://folio-org.atlassian.net/browse/MODFEE-29. Java type "double" is being used for monetary values, which is dangerous because it might potentially lead to wrong calculation results. This issue can be fixed independently, but if we're going to start major refactoring of Fees/fines it should also be part of it.