Aman-Mittal opened a new pull request, #806:
URL: https://github.com/apache/fineract-backoffice-ui/pull/806
Follow-up to #804, which it builds on. Part of #295.
Two more bugs of the kind #764 and #766 turned out to be — a field read at
the call site, by
string, from a payload shape nobody had written down — and the rest of the
deposits module moved
behind the ADR 0006 boundary so the next one cannot be written. Everything
below was measured
against a running `apache/fineract:latest` before it was written.
## Two user-visible bugs
**No product name on a deposit account.** The view bound `productName`. A
deposit account answers
`depositProductName`, and carries no `productName` key at all — so the
heading of every fixed and
recurring deposit account was blank.
**`0.00 %` against every deposit product.** Both product lists carried an
interest rate column.
`GET /{type}depositproducts` answers `nominalAnnualInterestRate: 0` for
every product it has ever
been asked about — measured across 59 fixed and 3 recurring, charts paying
5% and 7% among them —
and sends no chart to read the real figure from. One number is the wrong
shape for the answer in
any case: a deposit product prices by term, in bands. The lists now state
the two figures the
endpoint does answer, the deposit amount and the minimum term, and the rates
stay on the
product's own page where a chart can be shown as one.
The column is gone rather than corrected because the model it reads has no
rate to bind:
`DepositProductSummary` cannot offer a figure the payload does not have.
## The boundary, finished on both sides
**`DepositAccount.raw` is gone.** #804 left the account view binding most of
its template through
the payload record the mapped account carried, named as migration debt. That
record is what let
the heading read `productName`. The account's status flags, currency symbol,
stamped timeline
dates (as ISO), period-frequency id, maturity instruction and its own
rate-chart rows are now
modelled, and the screen reads no field by string. `DepositChartRow` is the
richer shape the
interest-rate-chart tab needs — amount band, description, incentives — which
neither generated
slab model declares.
**`DEPOSIT_PRODUCT_API` joins the account token.** The two product forms
were the same screen
written twice, each casting its own product to `Record<string, unknown>`
because the generated
response model omits eight fields an update has to resend — `inMultiplesOf`,
`maxDepositTermType`, `depositAmount`, `minDepositAmount`,
`maxDepositAmount`,
`preClosurePenalApplicable`, `accountingRule`, `activeChart`. Two copies of
a payload read is two
places for a field position to be wrong. They are declared once now, against
what the platform
sends, and the `isRD ? … : …` choice each screen made four times is one
branch per operation
inside the adapter. Chart mapping moves with it:
`chartFromResponse(unknown)` becomes
`chartFromProduct(DepositProductChart | null)`, so unwrapping
`periodType.id` is a fact about the
wire and the request envelope stays with the form.
**Six generated-client suppressions pruned, four files off the ratchet
entirely.**
## Measured platform facts, recorded where they are read
- a recurring deposit **product** reports no recurrence: one created with
`recurringFrequency: 1` answers neither `recurringDepositFrequency` nor
`recurringDepositFrequencyType` on its own read, and the account template
for that product
answers null for both. The form falls back to its default, as before — the
difference is that
the model says so instead of the blank reading as "none"
- a deposit **account** does not echo `maturityInstruction`, even with
`associations=all`
- `maxDepositTermTypeId: null` is refused outright: *"The parameter
`maxDepositTermTypeId` must
be one of [ 0, 1, 2, 3 ]"*
## Two regressions the e2e caught, and the unit tests had not
Both are in the series rather than hidden, because each says something worth
keeping:
1. **absent-as-null leaked into the request.** Modelling an unstated figure
as `null` is right for
a model and wrong for the body the forms spread it into: the platform
validates a null against
the field's enumeration instead of skipping it. No product the create
form makes has a maximum
term, so none of them could be edited. `absent()` puts the omission back,
and the test asserts
the field is off the serialised body rather than merely falsy.
2. **the date formatter stopped formatting transaction dates.** The
account's dates arrive as ISO
now; a transaction row is still an unmodelled payload record,
deliberately, carrying
`[year, month, day]`. The narrowed formatter threw `date.split is not a
function` once per
row, which emptied every cell of the row and took its undo button with
it, so a recorded
deposit could not be reversed from the list.
## Verification
- **2444 unit tests / 305 files**, green in UTC and in `America/New_York`;
`test:mfe` green
- **17 backend e2e** against `apache/fineract:latest`:
`deposit-product-configuration`,
`deposit-lifecycle-backend`, `deposit-account-servicing`,
`charge-servicing-backend`. The
product spec now asserts the list row's figures and that no `0.00 %` is
rendered
- mocked `deposit-product-edit` green — it drives the same URLs through the
new adapter unchanged
- `lint`, `lint:prune`, `prettier --check`, `check-api-surface` and the
repo's static checks all
exit 0
## Left for next
The deposit **account** lists and the three transaction screens still import
the generated client
(six suppressions). They need `list` and transaction operations on
`DepositAccountApi`, which is
the same shape of work again and is better reviewed on its own.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
