Aman-Mittal opened a new issue, #771:
URL: https://github.com/apache/fineract-backoffice-ui/issues/771
## Summary
The only money-moving transaction a Working Capital loan supports today is
**repayment**. Fineract supports several more transaction types on these loans,
and none of them is reachable from the UI.
## Evidence (`main` @ `8da1086f`)
- `src/app/features/working-capital/loans/wc-loan-action-form.component.ts`
handles `approve`, `disburse`, `reject`, `repayment`, `markasfraud`, `discount`
and `paymentrate`.
- Its only transaction call is
`postWorkingCapitalLoansLoanIdTransactions(this.loanId, 'repayment', …)` (line
~478).
## Platform support
`POST /v1/working-capital-loans/{loanId}/transactions?command=…`, with the
matching `GET …/transactions/template?command=…` for defaults:
| Command | Purpose |
|---|---|
| `repayment` with the prepay template | settle the full outstanding balance
early (amount from the template) |
| `goodwillCredit` | credit the borrower as a concession |
| `payoutRefund` | refund a merchant payout |
| `creditBalanceRefund` | pay out an overpaid (credit) balance |
## Proposed implementation
- Add **Prepay**, **Goodwill credit**, **Payout refund** and **Credit
balance refund** to the loan's action menu. Route each to `wc-loan-action-form`
with its command. Fill the date, amount and payment-type defaults from the
transaction template.
- **Prepay:** show the template's outstanding amount read-only.
- **Credit balance refund:** offer it only while the loan has a credit
(overpaid) balance.
- Refresh the transactions tab and summary after posting.
## RBAC
| Action | Permission code | Typically granted to |
|---|---|---|
| Prepay | `REPAYMENT_WORKINGCAPITALLOAN` (Fineract has no separate prepay
code) | teller, loan officer |
| Goodwill credit | `GOODWILLCREDIT_WORKINGCAPITALLOAN` | branch manager,
customer-service supervisor |
| Payout refund | `PAYOUTREFUND_WORKINGCAPITALLOAN` | operations / back
office |
| Credit balance refund | `CREDITBALANCEREFUND_WORKINGCAPITALLOAN` |
operations, branch manager |
Concessions and refunds should usually *not* be granted to the role that
takes repayments, so the UI must gate each action on its own code, not on
`UPDATE_WORKINGCAPITALLOAN`. See the related per-command RBAC issue for this
screen.
### How Fineract evaluates these permissions
- A write command passes when the user holds the exact code **or**
`ALL_FUNCTIONS`. Reads also pass with `ALL_FUNCTIONS_READ`.
- With maker-checker on, the command is queued for a `<CODE>_CHECKER`
holder. The UI must report "submitted for approval" instead of success.
- All codes above are present in `scripts/permission-codes.json`.
### UI expectations
- Map each command to its code. The pattern is the
`LOAN_COMMAND_PERMISSIONS` map in `src/app/core/guards/command-permissions.ts`;
this needs a Working Capital equivalent.
- Guard the action route per command.
- Gate each menu item with `[appRequiresPermission]`.
- Read-only roles see no enabled transaction actions.
## Acceptance criteria
- [ ] All four transactions can be posted and appear in the transactions tab.
- [ ] Defaults come from the transaction template.
- [ ] Each action is hidden or disabled for a user without its specific
code, and a direct URL redirects to `/forbidden`.
- [ ] Unit tests cover the payload for each command and the permission
gating.
--
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]
