[PR] feat(products): correct a deposit or savings transaction after it is recorded [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

Aman-Mittal opened a new pull request, #341:
URL: https://github.com/apache/fineract-backoffice-ui/pull/341

   ## What and why
   
   The transactions tables on the savings and term deposit screens could be read but never acted on. A teller who mis-keyed an amount had no reversal, and a hold placed against a claim could never be released from this application — money could be earmarked and then only freed outside the product.
   
   Closes #298. Also closes the last two rows of the table in #197 (`holdAmount` / `releaseAmount`, which was half-built: funds could be held but not freed).
   
   ## Verified against a running Fineract
   
   Probing the command discriminator on each endpoint:
   
   | Endpoint | Commands |
   |---|---|
   | `POST /savingsaccounts/{id}/transactions/{txId}` | `undo`, `modify`, `releaseAmount`, `reverse` |
   | `POST /recurringdepositaccounts/{id}/transactions` | `deposit`, `withdrawal` |
   | `POST /recurringdepositaccounts/{id}/transactions/{txId}` | `undo`, `modify` |
   | `POST /fixeddepositaccounts/{id}/transactions` | `deposit`, `withdrawal` |
   | `POST /fixeddepositaccounts/{id}/transactions/{txId}` | `undo`, `modify` |
   
   What the discriminator does **not** say, and the platform does:
   
   - **A fixed deposit refuses a withdrawal.** The command is enumerated but answers `503 error.msg.fixeddepositaccount.account.trasaction.withdraw.notallowed`. The screen offered *Withdraw* on every term deposit and navigated to a route that does not exist. It is now offered for recurring deposits only, where it works — money leaves a fixed deposit through maturity or premature closure, both already on the menu.
   - **`undo` is lenient.** It answers `200` against an already-reversed transaction, and against a hold or a release, doing nothing useful. **`releaseAmount` is strict**, refusing a second release with `validation.msg.amount.is.not.on.hold`. So the screens gate both themselves rather than offering a button that reports success and changes nothing.
   - **A hold records `releaseTransactionId` as `0` while it stands**, not as absent, so the release gate tests for a truthy id rather than for the key.
   
   ## The term deposit transactions tab was empty by construction
   
   It read `account['transactions']`, and neither `GET /fixeddepositaccounts/{id}` nor its recurring twin returns that key unless asked. So the tab showed nothing on every account regardless of activity.
   
   - **Fixed deposit** has a list endpoint and a generated method for it — that is the typed path and it is used.
   - **Recurring deposit** has neither. `GET /recurringdepositaccounts/{id}/transactions` answers `405`, and the upstream OpenAPI document describes no `associations` parameter for either deposit type — although it does for `/savingsaccounts/{accountId}`. That one read therefore goes through the same `HttpClient` escape hatch `group-view` already uses, with the condition for deleting it recorded in the comment.
   
   Worth raising upstream: `associations` is honoured by the platform on both deposit account GETs but missing from the spec.
   
   ## Reversed rows stay visible
   
   Struck through, marked, never removed — on both screens. Fineract flags `reversed` rather than deleting, and dropping the row would take the audit trail with it. Same failure class as #280.
   
   ## The fixed-deposit transaction form
   
   Did not exist. One trap worth flagging for reviewers: its generated operation is `(accountId, command, body)` where the recurring twin is `(accountId, request, command)`, and the body is typed `string`. A call copied from the twin binds the request object to `command` and **still compiles**. The spec asserts the argument positions explicitly.
   
   Two more spec-versus-platform gaps handled locally, both commented: `paymentTypeOptions` is typed `Array<number>` but arrives as objects (binding the raw element would render `[object Object]`), and `paymentTypeId` is absent from the request model although the platform accepts it and echoes it back under `changes`.
   
   ## Not touched
   
   `#279`/`#278` overlap with open PR #335, which fixes the recurring-deposit route and command. Nothing here changes that file or the recurring-deposit navigation.
   
   ## Verification
   
   - Unit: 909 pass, including the gating rules and the argument-order assertion.
   - Mocked e2e: 247 pass.
   - Real-backend e2e, both new:
     - a fixed deposit is approved, activated, a deposit recorded, listed on the tab, and reversed while staying on screen;
     - a savings hold is released and a savings deposit reversed.
   - `npm run lint`, `format:check`, `check:icons`, `i18n:check`, `build` all clean.
   
   ## Checklist
   
   - [x] I did not hand-edit generated files under `src/app/api/`.
   - [x] New component uses the adapter boundary (`| appTranslate`), per ADR-0003.
   - [x] New user-facing strings added to `en.json` and verified by hand — `scripts/check-translations.mjs` does not match `| appTranslate`.
   - [x] Commits are signed.
   


-- 
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: [PR] feat(products): correct a deposit or savings transaction after it is recorded [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

Aman-Mittal merged PR #341:
URL: https://github.com/apache/fineract-backoffice-ui/pull/341


-- 
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