Aman-Mittal opened a new issue, #400: URL: https://github.com/apache/fineract-backoffice-ui/issues/400
Part of #395. ## Problem `e2e/rbac-backend-restricted-user.spec.ts` is the only spec driving permissions against a real Fineract. It covers a single-permission route and one action-level gate, which leaves several dimensions of the permission model unproven: - **Routes declaring more than one permission code.** `permissionGuard` treats multiple codes as OR. Nothing tests that a user holding exactly one of them is admitted, or that a user holding none is refused. - **`ALL_FUNCTIONS_READ`.** Only ever exercised against a mocked session, never against Fineract's own permission catalogue, so agreement between our shortcut and the backend's is assumed rather than demonstrated. - **A second action-level gate.** Loan repayment is the only one covered; a single example does not show the pattern holds. - **Reload persistence.** Restricted permissions are only asserted on a fresh login. Whether they survive an actual page reload — rehydration from storage rather than from the login response — is untested, and that is exactly where a permission set tends to come back wrong. ## Expected Cover each dimension above, following the existing spec's shape: assert every refusal **both** as "the router sent them to Access Denied" **and** as "Fineract itself returned 403". The guard is defence-in-depth, and showing only the client-side half invites the conclusion that the client-side half is what protects the data. ## Notes Needs a real backend, so the spec belongs in `BACKEND_SPECS` in `playwright.config.ts`. Some assertions need `data-testid` hooks on action buttons that do not have them yet. -- 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]
