Aman-Mittal opened a new issue, #279:
URL: https://github.com/apache/fineract-backoffice-ui/issues/279
## Business value
The account view shared by fixed and recurring deposits offers two actions,
and neither reaches a screen.
`src/app/features/products/deposit-account-view.component.ts:367-375`:
```ts
onDeposit(): void {
this.router.navigate([`/products/recurring-deposits/${this.accountId}/transactions/deposit`]);
}
onWithdraw(): void {
const type = this.isRD ? 'recurring-deposits' : 'fixed-deposits';
this.router.navigate([`/products/${type}/${this.accountId}/transactions/withdrawal`]);
}
```
The only transaction routes declared in
`src/app/features/products/products.routes.ts` are:
```
fixed-deposits/:accountId/transactions (:345)
recurring-deposits/:accountId/transactions/create (:352)
```
So there are two separate defects:
1. **Neither target exists.** `.../transactions/deposit` and
`.../transactions/withdrawal` are not declared for either product, so both
buttons fall through to the catch-all and the user is bounced to the dashboard,
losing the account they were on.
2. **`onDeposit` ignores `isRD`.** On a *fixed* deposit account it still
builds a `recurring-deposits` URL. Even once a route exists, this sends the
user to the wrong product family.
The practical effect is that a term deposit account, once opened, can never
be transacted against from the UI. For an institution offering fixed or
recurring deposits, that is the whole product.
## Reproducing it
Open any fixed or recurring deposit account and press Deposit or Withdraw.
You land on the dashboard.
```
grep -n "transactions" src/app/features/products/products.routes.ts
grep -n "onDeposit\|onWithdraw"
src/app/features/products/deposit-account-view.component.ts
```
## Describing the change
Route the two actions at a screen that exists, and respect the account type.
The recurring-deposit transaction form is already built
(`recurring-deposit-transactions/recurring-deposit-transaction-form.component.ts`)
and routed at `recurring-deposits/:accountId/transactions/create`. The
fixed-deposit side has a transactions *list* but no form.
A reasonable shape, and the one the savings screens already use — see
`savings-account-view.component.ts:735`:
```ts
onTransaction(command: string) {
this.router.navigate([`/products/savings-accounts/${this.accountId}/transactions/${command}`]);
}
```
so a `:command` segment carrying `deposit` or `withdrawal`, with the form
reading it from the route.
**Two things to be careful about.**
1. **Derive the product family from `isRD` in both handlers**, not just
`onWithdraw`. The bug in `onDeposit` is a one-character-class fix but it is the
kind that comes back; a single private helper returning the prefix is better
than repeating the ternary.
2. **The recurring-deposit form currently cannot save** — it omits the
`command` query parameter the platform requires, so every submission 400s. That
is issue #278. Please do not fix it here; the two changes will conflict. If you
want the whole flow working end to end, say so on both issues and take them
together.
If wiring a fixed-deposit transaction form is more than you want to take on,
**fixing only the routing and the `isRD` bug is a complete and useful
contribution** — say so in the PR and leave the FD form to a follow-up.
## Testing
The platform's own acceptance tests give the required order. From
`fineract-e2e-tests-runner/src/test/resources/features/SavingsAccount.feature`
in `apache/fineract` (`develop`), scenario C2438:
```gherkin
And Client creates a new EUR savings account with "1 June 2022" submitted on
date
And Approve EUR savings account on "1 June 2022" date
And Activate EUR savings account on "1 June 2022" date
And Client successfully deposits 1000 EUR to the savings account on "1 June
2022" date
```
Note that approve and activate come first — a deposit to a pending account
is refused, so any test must walk the account through its lifecycle rather than
jumping to the transaction.
What to write:
- **A unit spec** on `deposit-account-view.component.ts` asserting the URL
each handler navigates to, for **both** `isRD === true` and `isRD === false`.
Four assertions. The `isRD` bug is invisible unless you test both branches.
- **A mocked e2e** that opens a deposit account, clicks Deposit, and asserts
the resulting URL matches the transaction route — `await
expect(page).toHaveURL(/\/transactions\//)`. Today this fails with `/dashboard`.
One trap worth knowing about, from an earlier e2e in this repo: list rows
are inert. The `routerLink` lives on the name cell, so `row.click()` does
nothing and the test sits on the list until it times out. Click the link inside
the row:
```ts
await row.getByRole('link').first().click();
```
## Scope
In scope: the two handlers, the missing route declarations, and the `isRD`
bug.
Out of scope: the missing `command` parameter (#278), and any change to the
transaction form's fields.
## Getting started
- Routes: `src/app/features/products/products.routes.ts`
- View: `src/app/features/products/deposit-account-view.component.ts`
- `npm test`, `npm run lint:prune` and `npm run build` must pass.
- `npm run e2e:stack` brings up a platform if you want to click through it.
--
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]
