Aman-Mittal opened a new issue, #272:
URL: https://github.com/apache/fineract-backoffice-ui/issues/272
## Summary
Fineract supports transferring a client between offices, with a
propose/accept handshake so the receiving branch consents. None of it is
reachable from the UI.
The platform advertises exactly twelve client commands. Sending an
unrecognised one makes it list them:
```
POST /clients/2?command=totallyNotACommand
→ 400 "The query parameter command has an unsupported value of:
totallyNotACommand"
args:
["activate","unassignStaff","assignStaff","close","proposeTransfer",
"withdrawTransfer","acceptTransfer","rejectTransfer",
"updateSavingsAccount","reject","withdraw","reactivate"]
```
The client detail view implements `activate`, `close`, `reject`, `withdraw`
and `reactivate`. The four transfer commands are absent, as is the one-step
`proposeAndAcceptTransfer` (which the command list omits but the platform
accepts, and which has its own permission code). A search across `src/app`
outside the generated client returns **zero** hits for any of them.
## Business Value
Branch reassignment is routine: a member moves house, a branch is split or
merged, an officer's book is rebalanced. Without it a branch has only bad
options.
Closing the client and re-creating them at the new office severs the loan
and savings history, so repayment behaviour is lost and the customer looks new
to credit assessment. Leaving the client at the old branch means their
portfolio is reported under an office they no longer belong to, which distorts
branch-level portfolio-at-risk and the field officer's caseload.
The handshake matters for the same reason. `proposeTransfer` moves the
client to "Transfer in progress" while leaving them at the source office; the
destination branch then accepts or rejects. That is the control that stops one
branch pushing delinquent accounts onto another, and it is a control the
institution currently cannot exercise at all.
## Verified command contracts
Probed against a local Fineract instance — a full propose → accept round
trip, and each refusal path. **Parameters differ per command and are strictly
validated**, so they cannot share one dialog shape:
| Command | Body | Result |
|---|---|---|
| `proposeTransfer` | `{locale, dateFormat, destinationOfficeId,
transferDate, note?}` | status → *Transfer in progress*; office unchanged |
| `acceptTransfer` | `{note?}` | status → *Active* at the destination office
|
| `rejectTransfer` | `{note?}` | status → *Transfer on hold*, still at the
source office |
| `withdrawTransfer` | `{note?}` | status → *Active* at the source office |
| `proposeAndAcceptTransfer` | `{destinationOfficeId, note?}` | status →
*Active* at the destination in one step |
Two traps worth recording, both confirmed by a 400 response:
- **`acceptTransfer` rejects `locale`, `dateFormat` and `transferDate`** —
`{"The parameter transferDate is not supported.", "The parameter dateFormat is
not supported.", "The parameter locale is not supported."}`. It takes an
optional note and nothing else, so it cannot reuse a date-bearing action dialog.
- **`proposeAndAcceptTransfer` rejects `transferDate`** even though
`proposeTransfer` requires it.
`withdrawTransfer` recovers from *both* pending states — verified from
"Transfer in progress" and from "Transfer on hold", returning the client to
Active at the source office. Without it, a rejected transfer strands the client
on hold with no way out of the UI.
Permission codes exist for each: `PROPOSETRANSFER_CLIENT`,
`ACCEPTTRANSFER_CLIENT`, `REJECTTRANSFER_CLIENT`, `WITHDRAWTRANSFER_CLIENT`,
`PROPOSEANDACCEPTTRANSFER_CLIENT`.
## Suggested implementation
- Menu items gated on both status and permission: propose/propose-and-accept
only when Active; accept/reject/withdraw only when a transfer is pending;
withdraw also when on hold.
- Office choices come from `GET /clients/{id}?template=true`, which already
returns `officeOptions` alongside `staffOptions` — no extra request.
- Surface the pending state on the header, otherwise "Transfer in progress"
is invisible and the destination branch has no cue to act.
- New components go through the adapter boundary per ADR-0003.
--
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]
