Aman-Mittal commented on PR #193:
URL: 
https://github.com/apache/fineract-backoffice-ui/pull/193#issuecomment-5156792799

   Pushed `930ed58`, which fixes a real bug in the previous commit that the 
backend e2e project caught.
   
   ### What was wrong
   
   Fineract only supports interest recalculation alongside **daily** interest 
calculation. Anything
   else is rejected with `not.supported.for.selected.interest.calculation.type` 
— and this form's own
   default, "same as repayment period", is one of the rejected values.
   
   So the control this PR adds produced a product the server refused: the user 
ticked the box, pressed
   Save, and stayed on the create page with a raw validation error.
   
   I confirmed it against a live Fineract before changing anything, rather than 
inferring it from the
   failure:
   
   ```
   interestCalculationPeriodType: 1  + recalculation → 400 
not.supported.for.selected.interest.calculation.type
   interestCalculationPeriodType: 0  + recalculation → accepted
   ```
   
   ### The fix
   
   The form sets daily when recalculation is switched on, locks the control and 
explains why — the
   same pattern as the repayment strategy lock on progressive products:
   
   > Fixed to Daily because interest recalculation is on — Fineract only 
supports the two together.
   > Turn recalculation off to choose a different period.
   
   Two unit tests cover it: that enabling recalculation moves the period from 
`1` to `0`, and that the
   explanation renders.
   
   ### The demo step was also wrong
   
   It left recalculation enabled on the cumulative product that the following 
ten steps lend against.
   A recalculating product constrains every loan created from it, so loan 
creation failed a few steps
   later — which is why the CI failure moved down the file rather than 
disappearing when I fixed the
   save.
   
   The step now shows the controls, including the locked note, and turns 
recalculation back off before
   saving. The demo is there to show the UI, not to change the product the rest 
of the walkthrough
   depends on.
   
   ### Verification
   
   I ran the **backend** project against a local Fineract this time, which is 
what I could not do when
   the PR was opened:
   
   | Check | Result |
   |---|---|
   | Backend Playwright (incl. the failing demo) | **16/16 passing** |
   | Mocked Playwright | **208/208 passing** |
   | Unit tests | **731 passing** |
   | `tsc`, build, lint, format, i18n, licence | all clean |
   
   One mocked test flaked once under three parallel workers and passed in 
isolation and on re-run; I
   added an explicit wait for the select to attach before driving it rather 
than leave that to CI's
   retries.
   
   ### Note
   
   This is the second thing in this phase that only a live backend would have 
caught, the first being
   the missing `IonCheckbox` import in #189. The mocked specs assert what the 
UI sends; they cannot
   assert that Fineract accepts it. Worth considering whether product-creation 
paths should have at
   least one backend-project test each, rather than relying on the demo to 
exercise them incidentally.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to