Aman-Mittal opened a new issue, #296:
URL: https://github.com/apache/fineract-backoffice-ui/issues/296
Part of #295.
## Business value
A term deposit account approved through the list row has no way to be
activated. Until it is activated it earns no interest and cannot be transacted
against, so the account is inert — and there is no way to reject or undo the
approval either, meaning a mistake is permanent.
This is the first sub-task of the epic because nothing else in it is
reachable on a real account without activation.
## What to build
An actions menu on `deposit-account-view.component.ts` carrying the
lifecycle commands the platform accepts for deposit accounts:
| Action | Needs |
|---|---|
| Activate | activation date |
| Reject | rejection date, reason |
| Undo approval | — |
| Withdraw by client | withdrawal date |
Gate each on the account's current status. A pending account can be
approved, rejected or withdrawn; an approved one can be activated or have its
approval undone; an active one can do none of these. Rendering a menu item the
platform will refuse is the failure mode to design against — the same menu
currently renders identically for pending, closed and matured accounts.
Introduce a named status constant object rather than integer literals in the
template. `src/app/features/clients/client-servicing.model.ts` is the pattern:
```ts
export const CLIENT_STATUS = { PENDING: 100, ACTIVE: 300, ... } as const;
```
## Two things to get right
1. **Confirm every payload against a live instance before writing the
dialog.** `npm run e2e:stack` brings one up. Do not assume the four commands
take the same fields — in this codebase `acceptTransfer` refuses the very
`locale`, `dateFormat` and `transferDate` that `proposeTransfer` requires. A
400 from Fineract names the offending parameter, and its `args` array often
enumerates accepted values.
2. **Fixed and recurring deposits share this view.** Check whether the
command set differs between them before assuming one menu serves both; if it
does, gate on `isRD` explicitly rather than letting the difference emerge as a
runtime error.
## Testing
- **Unit spec:** each action posts the expected command and body; assert
with `toEqual`, not `objectContaining` — whether `locale` is present is exactly
what you are pinning down.
- **Unit spec:** menu items appear and disappear with status. Cover pending,
approved, active and closed.
- **Mocked e2e:** intercept the `POST`, record `new
URL(request.url()).searchParams.get('command')` and the body. The `Probe`
pattern in `e2e/client-servicing-gaps.spec.ts` is the model.
- **Backend e2e** (add the file to `BACKEND_SPECS` in
`playwright.config.ts`): create → approve → activate a recurring deposit
entirely through the UI, and assert the status badge reads Active. No API
seeding.
One trap from an earlier backend e2e here: list rows are inert. The
`routerLink` sits on the name cell, so `row.click()` does nothing and the test
sits on the list until it times out. Use
`row.getByRole('link').first().click()`.
## Scope
In scope: the four lifecycle commands, status gating, status constants.
Out of scope: close and premature close (#297), transactions (#298), charges.
## Getting started
- `src/app/features/products/deposit-account-view.component.ts`
- Closest working model:
`src/app/features/products/savings-account-view.component.ts` — command
dispatch, dated commands and status gating are all there.
- `npm test`, `npm run lint:prune`, `npm run i18n:check`, `npm run build`
--
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]
