You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Aman-Mittal (via GitHub)" <gi...@apache.org> on 2026/10/16 09:21:17 UTC
[I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
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: issues-unsubscribe@fineract.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal commented on issue #798:
URL: https://github.com/apache/fineract-backoffice-ui/issues/798#issuecomment-6212336736
A clarification to the table above: a "—" in the *Success message* column means **not checked**. It does not mean "no message". I only checked for a success toast on client create, where none appeared. The savings and loan forms reference the toast service in source, so they may already confirm success. The navigation-to-list behaviour in those rows was observed live (savings) or confirmed in source (loan transactions), and is the main point of this issue.
--
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: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
Posted by "Iyamokuma (via GitHub)" <gi...@apache.org>.
Iyamokuma commented on issue #798:
URL: https://github.com/apache/fineract-backoffice-ui/issues/798#issuecomment-6226597286
Can you assign this issue to me?
--
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: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub) via issues" <is...@fineract.apache.org>.
Aman-Mittal closed issue #798: [Workflow] After a save or lifecycle action, return to the affected record and confirm success
URL: https://github.com/apache/fineract-backoffice-ui/issues/798
--
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: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal commented on issue #798:
URL: https://github.com/apache/fineract-backoffice-ui/issues/798#issuecomment-6231554908
@Iyamokuma Please create PR directly
--
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: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Workflow] After a save or lifecycle action, return to the affected record and confirm success [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub) via issues" <is...@fineract.apache.org>.
Aman-Mittal commented on issue #798:
URL: https://github.com/apache/fineract-backoffice-ui/issues/798#issuecomment-6739626255
This is done on `main`, so I am closing it rather than leaving it open on work that has already landed.
The shared helper this asked for exists as `src/app/core/services/mutation-outcome.service.ts`. `complete()` does all three things the acceptance criteria name: it resolves the new record's id (`recordId` when the caller already knows it, otherwise `extractMutationResourceId(response)`), navigates to that record's page, and raises a success toast — or, when `isMakerCheckerPending(response)` is true, `COMMON.MUTATION_SUBMITTED_FOR_APPROVAL` instead of the success message. A create whose response carries no id falls back to the list rather than navigating nowhere.
Eleven forms call it, which covers every one this issue listed:
```
src/app/features/clients/client-form.component.ts
src/app/features/clients/kyc/client-family-member-form.component.ts
src/app/features/groups/group-form.component.ts
src/app/features/centers/center-form.component.ts
src/app/features/loans/loan-form.component.ts
src/app/features/loans/loan-transaction-form.component.ts
src/app/features/products/savings-account-form.component.ts
src/app/features/products/savings-account-transaction-form.component.ts
src/app/features/products/account-action-form.component.ts
src/app/features/products/fixed-deposit-transactions/fixed-deposit-transaction-form.component.ts
src/app/features/products/recurring-deposit-transactions/recurring-deposit-transaction-form.component.ts
```
Spot-checking the three the issue quoted from source: `client-form.component.ts` passes `recordRoute: (id) => ['/clients/view', id]` on both the create and the update path, `savings-account-transaction-form.component.ts` navigates to `['/products/savings-accounts/view', accountId]`, and `loan-transaction-form.component.ts` to `['/loans/view', loanId]`. None of them goes to a list on success any more.
The four-searches-to-fund-one-account sequence this was filed about now stays on the account through create → approve → activate → deposit.
Closing as completed. If any form still lands on a list after a save, that is worth its own issue naming the form, rather than reopening this.
--
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: issues-unsubscribe@fineract.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org