Aman-Mittal opened a new issue, #798:
URL: https://github.com/apache/fineract-backoffice-ui/issues/798
#### Summary
Many forms in the back office send the user to the **list** page after a
successful save or account action, rather than to the record they were working
on. Some forms also show no success message.
Account opening is a chain of steps (create → approve → activate → deposit),
so the operator has to find the same account again in the list after every step.
#### Current behavior
Observed live while opening and funding a savings account, and creating
clients:
| Action | Where the user lands | Success message |
|---|---|---|
| Create client | `/clients` (list) | none |
| Edit client | `/clients` (list) | none |
| Create savings account | `/products/savings-accounts` (list) | — |
| Approve savings account | `/products/savings-accounts` (list) | — |
| Activate savings account | `/products/savings-accounts` (list) | — |
| Deposit / Withdraw | `/products/savings-accounts` (list) | — |
| Loan transaction (repayment etc.) | `/loans` (list), per source | — |
| Fixed-deposit transaction | the account page ✓ | — |
In source (`main` @ `8da1086f`):
- `client-form.component.ts` calls `router.navigate([this.LIST_PATH])` on
success of both create and update, and doesn't call the toast service. The
group form does the same.
- `savings-account-transaction-form.component.ts` navigates to
`['/products/savings-accounts']`, and `loan-transaction-form.component.ts` to
`['/loans']`.
- The fixed-deposit transaction form already returns to the account
(`['/products/fixed-deposits/view', accountId]`), which shows the intended
pattern.
#### Expected behavior
- After **creating** a record, open the new record, using the id returned in
the response (`clientId`, `savingsId`, `loanId`, …).
- After **editing** a record or running an **action** on it, return to that
record's page with refreshed data.
- Show a short, consistent success confirmation for every mutating action
("Client created", "Deposit of 100.00 posted"). When maker-checker queues the
command instead, say so.
#### Steps to reproduce
1. Create a client and save. You land on the client list with no
confirmation.
2. Create a savings account for that client, then approve it. You land on
the savings list.
3. Find the account again and activate it. You land on the list again.
4. Find it again and post a deposit. You land on the list again.
#### User impact
- Opening and funding one savings account took four separate searches for
the same record.
- With no confirmation, users can't be sure the save succeeded. That
encourages re-submitting, which together with #756 (double submit) can create
duplicates.
- New clients appear at the top of the list, which is easy to misread when
several staff are creating clients at once.
#### Evidence
- E2E run on 2026-10-16: client #6 and #7 created, and savings account #6
created, approved, activated, credited with a 100 deposit and debited with a 20
withdrawal. Every step returned HTTP 200 and redirected to the list. The final
balance of 80 was verified on the account page and through `GET
/savingsaccounts/6`.
- For client creation, a 200 ms poll for `ion-toast` elements from Save
until 3 s after the response found none.
#### Proposed improvement
- Introduce a shared "after mutation" helper. It navigates to the record
page by id (or stays on the current record for actions) and shows a translated
success toast. If the response carries a pending maker-checker command, the
toast says the change was submitted for approval.
- Apply it to the client, group and centre forms, to the savings, loan and
recurring-deposit transaction forms, and to the account action form.
#### Acceptance criteria
- [ ] Creating a client, group, loan or savings account opens the new record.
- [ ] Editing or running an action on a record returns to that record with
fresh data.
- [ ] Every successful create, update, action and transaction shows a
success message. Maker-checker submissions show a "submitted for approval"
message instead.
- [ ] Unit tests assert the navigation target and the toast for each updated
form.
#### Verification status
Reproduced on the deployed `main` (2026-10-16), superuser, tenant `default`.
The navigation targets were confirmed in source.
#### Related API capabilities
None needed. The create responses already return the new resource id
(`resourceId`, plus `clientId`, `savingsId` or `loanId`), and command responses
carry `commandId` when maker-checker applies.
Related: #756 (duplicate submissions).
--
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]
