Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2445

Refactoring of Fees/Fines Actions

    XMLWordPrintable

    Details

    • Template:
    • Epic Link:
    • Front End Estimate:
      XL < 15 days
    • Back End Estimate:
      XXL < 30 days
    • Confidence factor:
      Medium
    • Development Team:
      Vega
    • Calculated Total Rank:
      15
    • 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 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

              Activity

                People

                Assignee:
                hollyolepm Holly Mistlebauer
                Reporter:
                hollyolepm Holly Mistlebauer
                Front End Estimator:
                Maxim Didenko Maxim Didenko
                Back End Estimator:
                Alexander Kurash Alexander Kurash
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases