Aman-Mittal opened a new pull request, #187:
URL: https://github.com/apache/fineract-backoffice-ui/pull/187
Closes #186.
The loan **product** screens already model the two schedule engines
properly. The loan **account**
screens did not — every loan got the same tabs and the same requests
regardless of which engine it
runs on, and `isProgressiveLoan()` was used for exactly one thing: the
colour of a chip.
### What was wrong
**Two permanently empty tabs on every cumulative loan.** Buy-down fees and
capitalised income are
progressive-engine capabilities, so on a cumulative loan those tabs could
never hold anything. The
user sees an empty table with no way to tell *none recorded* from *not
applicable*.
**Two wasted requests per loan view.** Both tabs fetched unconditionally for
any loan with an
external id, with `error: () => { /* ignored */ }`, so nothing ever surfaced
the waste.
**A strategy that could contradict its own product.** The loan application
form copies the
repayment strategy from the product, but fell back to
`mifos-standard-strategy` when the product
detail request had not resolved — the one code a progressive product may
never carry — and the
fallback was not guarded by schedule type.
### What changed
Both tabs are gated on the loan's own `enableBuyDownFee` /
`enableIncomeCapitalization` flags,
which `GET /loans/{id}` already returns. That is deliberately stricter than
gating on schedule
type: progressive alone is not enough, the product has to have enabled the
feature. The requests
are gated the same way, and the active tab falls back to the overview if a
tab disappears once the
loan resolves.
The form now reads the schedule type from the list row when the detail
request is unavailable,
picks the strategy the engine requires, and corrects a strategy that
contradicts a progressive
product before submitting.
`requiredStrategyFor`, `isProgressiveScheduleType` and the
`loanScheduleType` readers move into
`loan-schedule-type.ts`, so the cast that reaches a field the generated list
model omits exists
once rather than at each call site.
### Comprehensibility
Schedule type is the most consequential choice on a loan product and its
vocabulary is not
self-explanatory. The schedule type, repayment strategy, processing type and
both allocation
editors now carry plain-language help, and the locked strategy field says
*why* it is locked
rather than only greying out:
> Fixed to Advanced Payment Allocation because this is a Progressive product
— the two go together
> and Fineract rejects any other pairing.
### Tests
Schedule type had **no unit coverage at all**, and its only end-to-end
coverage was real-backend
and exercised the progressive direction only. This adds:
- unit tests for the schedule-type helpers, including that an unknown type
resolves to cumulative
rather than guessing progressive;
- unit tests for tab gating in **both** directions — present when the
capability is reported,
absent and unfetched when it is not, and the fallback when a hidden tab is
selected;
- `e2e/loan-schedule-type-gating.spec.ts`, **mocked** so the gating runs in
the fast CI project
rather than behind a live Fineract. It counts the requests, so "does not
fetch" is asserted
rather than assumed;
- demo steps showing the locked-strategy explanation and asserting the
cumulative loan does not
offer the progressive-only tabs.
### Verification
| Check | Result |
|---|---|
| Unit tests | **707 passing** (690 → 707) |
| Mocked Playwright | **195/195 passing** (192 → 195) |
| `tsc` (app + spec) | 0 errors |
| `npm run build` | passes |
| lint (empty suppressions baseline), format, i18n, icons, license | all
clean |
I also checked the new spec actually catches the regression: with the gate
reverted, **2 of its 3
tests fail**; restored, all 3 pass. And I drove the screens by hand against
mocks before committing
— a cumulative loan renders 9 tabs, a progressive loan with both
capabilities renders 11:
```
cumulative = [Overview, Repayment Schedule, Transactions, Charges, Custom
Fields,
Notes, Documents, Disbursement Details, Collateral Management]
progressive = [... , Buy-Down Fees, Capitalized Income, Disbursement Details,
Collateral Management]
```
### Not in this PR
The demo step is exercised only by the `backend` project, which needs a live
Fineract, so it is
unverified here — the assertions mirror the mocked spec that does run.
Down payment, interest recalculation, `multiDisburseLoan` and charge-off
still have no product-form
UI, and the repayment schedule still has no period-type column, so a
down-payment period is
indistinguishable from a regular instalment. Those are separate gaps
recorded in #186's research
rather than silently folded in here.
--
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]
