Details
-
New Feature
-
Status: Closed (View Workflow)
-
P1
-
Resolution: Done
-
None
-
-
XL < 15 days
-
Medium
-
XXL < 30 days
-
Vega
-
-
98
-
R2
-
R1
Description
The Vega team has identified major refactoring of functionality related to fees/fines. During the past few months they've discovered multiple issues, some of which are posing significant risks but can't be addressed without design changes.
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 is this approach 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). We were following this pattern for some time, but now it feels like we're just creating more technical debt because all of this will need to be refactored.
Bugs
While working on UIU-1139 Max has found a bug (UIU-1626) 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. This bug is not easy to fix and, again, it feels like by fixing it we're just investing in a bad design. (Note: This is a regression--it did not occur in Edelweiss.)
Double vs. BigDecimal
In February Vega created a technical debt ticket 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.
TestRail: Results
Attachments
Issue Links
- blocks
-
UIU-1139
Refund fees/fines: Enter refund
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is defined by
-
MODFEE-56
[SPIKE] Fees/fines refactoring estimation
-
- Closed
-
-
MODFEE-79
Create check-pay endpoint
-
- Closed
-
-
MODFEE-80
Create check-waive endpoint
-
- Closed
-
-
MODFEE-81
Create check-transfer endpoint
-
- Closed
-
-
MODFEE-82
Create check-refund endpoint
-
- Closed
-
-
MODFEE-83
Create pay endpoint
-
- Closed
-
-
MODFEE-84
Create waive endpoint
-
- Closed
-
-
MODFEE-85
Create transfer endpoint
-
- Closed
-
-
MODFEE-86
Create refund endpoint
-
- Closed
-
-
MODFEE-104
Create cancel endpoint
-
- Closed
-
-
MODFEE-105
Create check-pay endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-106
Create pay endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-107
Create check-waive endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-108
Create waive endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-109
Create check-transfer and check-waive endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-110
Create transfer endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-111
Create check-refund endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-112
Create refund endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-113
Create cancel endpoint for multiple selected accounts
-
- Closed
-
-
MODFEE-126 Fee/fine cancellation endpoint does not create fee/fine actions correctly
-
- Closed
-
-
UIU-1793
Refactor pay action
-
- Closed
-
-
UIU-1794
Refactor Waive action
-
- Closed
-
-
UIU-1795
Refactor transfer action
-
- Closed
-
-
UIU-1796
Refactor error action
-
- Closed
-
-
UIU-1797
Refactor actions for single list item
-
- Closed
-
-
UIU-1798
Refactor actions for multiple selected list items
-
- Closed
-
-
UIU-1799
Refactor deselect functionality for group actions
-
- Closed
-
-
UIU-1836
Refactor charge and pay action
-
- Closed
-
-
UIU-1850
Add refund action
-
- Closed
-