Aman-Mittal opened a new pull request, #199:
URL: https://github.com/apache/fineract-backoffice-ui/pull/199
Closes #198. Part of #197.
The savings account screen offered approve, activate, close, deposit and
withdrawal. None of the
servicing commands Fineract exposes were available — so posting interest,
the most ordinary
operation on a savings book, had to be done outside this application, and an
account could not be
frozen at all.
| Command | Offered when |
|---|---|
| `calculateInterest`, `postInterest`, `applyAnnualFees` | account is active
|
| `block` | active, not already frozen |
| `blockDebit` / `blockCredit` | active, not already frozen and that block
not in force |
| `unblock` / `unblockDebit` / `unblockCredit` | the matching block is
actually in force |
### Contracts probed, not inferred
As with the loan servicing work, every contract was checked against a
running Fineract first —
the generated client documents none of it.
- These are accepted on `POST /savingsaccounts/{id}?command=` with nothing
beyond `dateFormat`
and `locale`.
- **A block lives in `subStatus`, not `status`.** Fineract leaves a frozen
account `Active`, so the
status badge alone cannot distinguish one. The screen now shows a marker
naming which block is
in force.
- **Fineract rejects a reversal when the matching block is not in place** —
`unblockDebit` answers
*"debits.are.not.blocked"* — so each is offered only in the state that
permits it.
- **The three block types draw from three different code lists**:
`SavingsAccountBlockReasons`,
`DebitTransactionFreezeReasons`, `CreditTransactionFreezeReasons`. A
shared lookup would offer
reasons the server rejects, so the dialog is told which list to read and
resolves it **by name**,
since the ids differ per deployment.
- On a fresh Fineract **those lists exist but are empty**. That would
present an empty dropdown and
an unpressable button, so the dialog says so and points at where reasons
are configured.
### Comprehensibility
"Block debit" and "block credit" are easy to get backwards, and the
consequence of picking wrong is
either a customer locked out of their own money or one draining an account
under investigation. So
the actions are named by consequence — **Stop Withdrawals**, **Stop
Deposits**, **Freeze Account** —
and each confirmation says what still works:
> Stop withdrawals from this account? Deposits still go through — the
customer can pay in but
> cannot take money out.
### Verification
| Check | Result |
|---|---|
| Unit tests | **744 passing** (741 → 744) |
| Mocked Playwright | **210/210 passing** |
| `tsc` (app + spec), build, lint, format, i18n, icons, licence | all clean |
The block flow was verified end to end against a running Fineract: a reason
was configured, the
block accepted, `subStatus.block` observed as `true`, and the account
restored with `unblock`.
Three icons were unregistered and would have rendered as blank space; the
icon check caught them.
The savings spec needed `provideIonicTesting` once the component began
injecting `DialogService`.
### Not in this PR
**No automated backend spec.** The contracts were verified manually as
described, but there are no
e2e helpers for seeding a savings account the way `createActiveLoan` does
for loans, and writing
them is a larger piece than this change. That helper is the natural next
step before more savings
work lands — I would rather say so than imply the coverage exists.
Still open under #197: `assignSavingsOfficer`, `reject` /
`withdrawnByApplicant` on pending
applications, `holdAmount` / `releaseAmount` (on the transactions endpoint,
and it rejects a
parameter named `amount`), and GSIM group savings.
--
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]
