Aman-Mittal commented on issue #109: URL: https://github.com/apache/fineract-backoffice-ui/issues/109#issuecomment-5306477294
Implemented in #368, using the existing `*appHasPermission` directive as this issue asks — no new abstraction. **Dashboard entity cards.** The dashboard is the one screen every user lands on, so it is the one screen where a user is guaranteed to meet cards their role does not cover. The Clients, Loans and Savings widgets, the two distribution charts, and the pending-approvals card are now gated by `READ_CLIENT` / `READ_LOAN` / `READ_SAVINGSACCOUNT`. Gating the cards turned out to be the smaller half. The component also *requested* all of those metrics unconditionally, so a user without the permissions met a row of 403s and their error toasts on arrival — and because the requests are combined with `forkJoin`, which fails fast, a single refusal zeroed every other metric alongside it. The separate pending-loans call had no `catchError` at all. The component now decides what to request by the same rule that decides what to show, so a user with no permissions issues no requests and still gets a working page. **List screens.** `app-data-table` gained a `createPermission` input, and all **58** list screens with a create button now name the permission their own create route declares. The button is withheld rather than left to lead to Access Denied. **Detail screens.** `loan-view` had 4 gated actions out of 33; the remaining 29 — approve, disburse, reject, write-off, charge-off, waive, repayment, re-age, re-amortize, the refund variants — are now gated with the code Fineract requires for each. While doing this, four permission codes already in use turned out not to exist in Fineract's catalogue, so the controls behind them were invisible to everyone except `ALL_FUNCTIONS` holders: `CREATE_CLIENTFAMILYMEMBER` (really `..._FAMILYMEMBERS`), `CREATE_NOTE` (`..._CLIENTNOTE`), `CREATE_DELINQUENCYBUCKET` (`..._DELINQUENCY_BUCKET`), and `READ_LOANCOLLATERAL` (`READ_COLLATERAL`). All corrected against `GET /v1/permissions` on a running instance. Not exhaustive across all 291 components, and the PR says so. The privileged surfaces the audit identified are covered, and every route behind the rest is now gated — so an ungated control leads to Access Denied rather than to an unauthorized operation. -- 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]
