Fees/Fines (UXPROD-792)

[UXPROD-2445] Refactoring of Fees/Fines Actions Created: 29/May/20  Updated: 31/Aug/21  Resolved: 14/Oct/20

Status: Closed
Project: UX Product
Components: Fees/Fines
Affects versions: None
Fix versions: Q3 2020
Parent: Fees/Fines

Type: New Feature Priority: P1
Reporter: Holly Mistlebauer Assignee: Holly Mistlebauer
Resolution: Done Votes: 0
Labels: feesfines, mandatory, resourceaccess
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-106 Refund paid fees/fines and create rep... Closed
blocks UXPROD-2717 Refund paid fees/fines and create rep... Closed
blocks UIU-1139 Refund fees/fines: Enter refund Closed
Defines
is defined by MODFEE-56 [SPIKE] Fees/fines refactoring estima... Closed
is defined by MODFEE-79 Create check-pay endpoint Closed
is defined by MODFEE-80 Create check-waive endpoint Closed
is defined by MODFEE-81 Create check-transfer endpoint Closed
is defined by MODFEE-82 Create check-refund endpoint Closed
is defined by MODFEE-83 Create pay endpoint Closed
is defined by MODFEE-84 Create waive endpoint Closed
is defined by MODFEE-85 Create transfer endpoint Closed
is defined by MODFEE-86 Create refund endpoint Closed
is defined by MODFEE-104 Create cancel endpoint Closed
is defined by MODFEE-105 Create check-pay endpoint for multipl... Closed
is defined by MODFEE-106 Create pay endpoint for multiple sele... Closed
is defined by MODFEE-107 Create check-waive endpoint for multi... Closed
is defined by MODFEE-108 Create waive endpoint for multiple se... Closed
is defined by MODFEE-109 Create check-transfer and check-waive... Closed
is defined by MODFEE-110 Create transfer endpoint for multiple... Closed
is defined by MODFEE-111 Create check-refund endpoint for mult... Closed
is defined by MODFEE-112 Create refund endpoint for multiple s... Closed
is defined by MODFEE-113 Create cancel endpoint for multiple s... Closed
is defined by MODFEE-126 Fee/fine cancellation endpoint does n... Closed
is defined by UIU-1793 Refactor pay action Closed
is defined by UIU-1794 Refactor Waive action Closed
is defined by UIU-1795 Refactor transfer action Closed
is defined by UIU-1796 Refactor error action Closed
is defined by UIU-1797 Refactor actions for single list item Closed
is defined by UIU-1798 Refactor actions for multiple selecte... Closed
is defined by UIU-1799 Refactor deselect functionality for g... Closed
is defined by UIU-1836 Refactor charge and pay action Closed
is defined by UIU-1850 Add refund action Closed
Epic Link: Fees/Fines
Front End Estimate: XL < 15 days
Front End Estimator: Maxim Didenko
Front-End Confidence factor: Medium
Back End Estimate: XXL < 30 days
Back End Estimator: Alexander Kurash
Development Team: Vega
PO Rank: 98
Rank: 5Colleges (Full Jul 2021): R2
Rank: MO State (MVP June 2020): R1

 Description   

Design Document on Wiki

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 Closed Max has found a bug ( UIU-1626 Closed ) 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 Closed . 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.



 Comments   
Comment by Cate Boerema (Inactive) [ 26/Jun/20 ]

Hi Darcy Branchini can you please get estimates for this feature so we can do the cap planning?

Comment by Darcy Branchini [ 30/Jul/20 ]

Groomed on 7/28, Maxim Didenko will add FE stories, then it should be ready for development.

Generated at Fri Feb 09 00:24:02 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.