Aman-Mittal opened a new pull request, #310:
URL: https://github.com/apache/fineract-backoffice-ui/pull/310
Closes #265.
Share accounts could be created and edited but never opened — no detail
component, no route to one — so everything an operator does after the
application was unreachable: approving it, activating it, buying more shares,
redeeming some, closing the account.
## The commands
The platform exposes nine on these accounts. Unlike the group and deposit
resources, `/accounts/share` does **not** enumerate them when handed an unknown
command — it just says `SHAREACCOUNT|TOTALLYNOTACOMMAND is not supported` — so
each was probed individually against a running Fineract:
```
approve · reject · activate · undoapproval · close
applyadditionalshares · approveadditionalshares · rejectadditionalshares ·
redeemshares
```
They disagree about their date field — `approvedDate`, `rejectedDate`,
`activatedDate`, `closedDate`, `requestedDate` — so each command names its own
rather than sharing a guess, and `undoapproval` takes an empty body. All of it
verified by running the lifecycle against a real platform before writing the
screen.
`approveadditionalshares` / `rejectadditionalshares` are out of scope: they
act on individual purchase rows rather than the account, which is a different
interaction.
## What the screen does
Header with status, an actions menu gated on the status booleans Fineract
returns beside the id (not on `status.value`, which is the server's English
label), and three tabs — overview, share purchases and redemptions, dividends.
Buying and redeeming take the same pair, a date and a share count, so they
share one dialog and differ only in direction. A redemption is **bounded by the
holding**, which the dialog is given: the platform refuses a larger one, but it
refuses it after a teller has committed to a number that was already on screen.
Command dates are floored at the date the platform stamped, for the reason
established in #303 and #307.
## Two findings worth recording, neither introduced here
**The share accounts list is permanently empty.** `GET /accounts/share`
answers `totalFilteredRecords: 0` under every parameter combination — plain,
`offset`/`limit`, `paged`, `clientId` — with four accounts present, while `GET
/clients/{id}/accounts` returns them fine. So the detail screen is reached by
route, and the list's new View button will only become useful once that list is
re-sourced. That is its own change; happy to file it.
**Share products live at `/products/share`, not `/shareproducts`** — which
corrects what I wrote on #309. The template there *does* return
`accountingMappingOptions` (asset, liability, income), but no
`accountingRuleOptions`. So #293 is less blocked than I said: the account
options exist, only the rule list does not.
## Verifying it
`e2e/share-account-servicing.spec.ts` drives approve → undo approval →
approve → activate → buy 50 shares → redeem 10 → close through the screens
against a real Fineract, asserting the menu changes with the status and that a
closed account offers nothing further. A second test covers rejection.
| | |
|---|---|
| `share-account-servicing.spec.ts` (real backend) | 2 passed |
| `share-account-view.component.spec.ts` | 9 new |
| Full unit suite | 883 passed |
| `npm run lint`, `npm run build`, `tsc` | clean |
The account is seeded through the API and everything after it driven through
the UI — the split `createActiveLoan` uses. Seeding is more involved here than
elsewhere and the helper documents why: a share account requires an **active**
linked savings account for dividends, and the share product needs
`nominalShares` plus `minimumactiveperiodFrequencyType: 0`, both of which fail
with validation that does not say much.
--
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]
