Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
40 minCheck-insEveryone

Introductions

Check-Ins

For each student please create a new Level 2 entry and enter the following. 

Dylan Robson

I found the final root cause that made interest due be miscalculated on the first day of the month for the LoanReschedulingWithinCenter integration test. (FIN-722).

It turned out, there were other integration test(s) - like GlobalConfigurationTest - which changed global configuration values but they were never reset to their defaults between integration tests. So when LoanRescheduleWithinCenterTest tried to test loan interestDue on Jan 1, 2019, it failed due to those altered configurations (significantly, the "skip-repayment-on-first-day-of-month" configuration was modified to true).

I explored 3 different implementations to resolve this

  1. Hardcoding REST API requests to reset what I noticed were the default global configuration values. This approach was by far the fastest, but doesn’t seem like a good long term approach because it only reset c_configuration table, and it doesn’t account for migrations, and it doesn’t account that a default value could change.
  2. Tried running Flyway Gradle tasks through Java using Runtime exec(...). This approach felt hacky and unreliable, so I figured I should try my 3rd idea.
  3. Used Flyway Java API directly. This approach took a very long time to run and I think it would add several minutes to integration test suite runtime. It was the most future-proof solution though because it clean and reapplied migrations, so these global config defaults would always be up to date.
    1. Another option would be available once the Flyway dependency was upgraded (currently an open PR). Once upgraded, a one-liner @FlywayTest annotation could clean / migrate DB to fresh state for each test class/method. However I think this would have the same effect on runtime as the 3rd implementation.
    2. I may be able to find some way to reduce this runtime w/ setting Flyway’s init description/version field. I don’t think I can migrate a single table because the tables are interdependent.

Made PR changes for my FIN-609 PR regarding an updated SQL query.

I also spent a little bit of time further exploring FIN-723.

Add integration test case(s) for my FIN-609 PR update.

Finalize and submit PR for FIN-722.

Move forward with FIN-723 as my primary focus.

Receive further feedback about which implementation to FIN-722 would be preferred. I emailed dev list yesterday, but I think I might need to further elaborated, as I forgot to mention the negative runtime implications of my 3rd approach.

Already in contact. I need to further elaborate and re-ping my email on the Fineract dev list from yesterday.

Further elaborate on my last email to the dev list and ask whether implementation 1 or 3 is preferred.

Abhay Chawla

Apoorva K

Supreeth Menon

Cajetan Rodrigues

Moksh Mahajan

Shivansh Tiwari

Saksham Handu

Massabe Lydiane

I finished updating all the pages under the Administrator part if the user manual

I started updating the pages under "Accounting Operations" under "For Operational Users" section of the manual 

I will continue updating the pages under the "For Operational Users" section of the manual 

none

none

Anshul Singh

Abhijit Ramesh

Prashant Khandelwal

Jivjyot Singh

Ebenezer Graham

Sidhant Gupta

Manish Kumar

Kerlyn Nkep

Dundi Raja Vamsi Reddy

Kang Breder


Action items