Aman-Mittal opened a new issue, #295:
URL: https://github.com/apache/fineract-backoffice-ui/issues/295
## Business value
Fixed and recurring deposit accounts can be created and approved from a list
row, and that is where it ends.
`src/app/features/products/deposit-account-view.component.ts:367-375` — the
entire action menu on the shared deposit account view is Deposit and Withdraw,
and both navigate to routes that do not exist:
```ts
onDeposit(): void {
this.router.navigate([`/products/recurring-deposits/${this.accountId}/transactions/deposit`]);
}
```
The only transaction routes declared in `products.routes.ts` are
`fixed-deposits/:accountId/transactions` (`:345`) and
`recurring-deposits/:accountId/transactions/create` (`:352`). Neither target
exists, and `onDeposit` ignores `isRD` so a fixed deposit builds a
recurring-deposit URL.
Missing entirely: **activate, reject, undo approval, withdraw by client,
close, premature close, interest posting**. There is no charges tab, no
transactions tab with a correction path, and no way to see the maturity
position.
So a member opens a term deposit, the branch approves it, and then nobody
can activate it — which means it never starts earning, never matures, and never
pays out. Two entire product families are non-operational past creation.
Recurring deposits in particular are a staple group-savings product; a
branch that cannot record instalments against one cannot offer it.
## Related work already filed
- **#279** — the two dead navigation targets and the `isRD` bug. Small,
self-contained, good first issue.
- **#278** — the recurring-deposit transaction form omits the `command`
query parameter the platform requires, so every submission returns 400.
Confirmed by probe against a live instance.
Those two are the minimum to make the existing screens honest. **This epic
is the work beyond them.** Neither is a prerequisite for the sub-tasks here,
but landing them first avoids building on top of a broken form.
## Sub-tasks
Split so each is independently shippable. The lifecycle actions come first —
without activation nothing else in the epic is reachable on a real account.
## Scope
In scope: the shared deposit account view, its lifecycle actions,
transactions, charges, and the fixed-deposit transaction form.
Out of scope: deposit *product* configuration, including the destructive
edit path — that is #292. Savings accounts, which have their own servicing gaps
(#197).
## Getting started
- Shared view: `src/app/features/products/deposit-account-view.component.ts`
- Routes: `src/app/features/products/products.routes.ts`
- The savings account view (`savings-account-view.component.ts`) is the
closest working model in the codebase — it has the command dispatch, block
reasons and status gating patterns to copy.
- Every command payload must be confirmed against a live instance. `npm run
e2e:stack` brings one up. Commands in this API are routinely asymmetric about
`locale` and `dateFormat`, and a 400 usually enumerates the accepted values in
its `args` array.
## Verification
Open a recurring deposit account through the UI, approve it, activate it,
record two instalments, and confirm the transactions tab shows both with a
running balance. That flow — not the menu rendering — is the definition of done.
--
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]
