Aman-Mittal opened a new issue, #666:
URL: https://github.com/apache/fineract-backoffice-ui/issues/666
Fineract scopes most portfolio reads to the signed-in user's office subtree.
The Offices screen opts out of that: it requests `includeAllOffices=true`, so a
user belonging to a single branch is shown every office in the institution.
Verified with a seeded branch-scoped user holding `READ_CLIENT` and
`READ_OFFICE`:
```
GET /offices -> 200
GET /offices?includeAllOffices=true -> 200
```
Both succeed. **The platform is willing to answer either way — the client
chooses the wider body.** The difference is in the response, not the status,
which is why this is a UI decision rather than something Fineract is enforcing
or refusing.
For contrast, the same user's client list *is* scoped: they see their
branch's client and not Head Office's, and `GET /clients/{headOfficeClient}`
answers 404 for them.
## Why this is a question and not a bug report
There is a reasonable case for either behaviour, and I could not establish
which is intended:
- **Keep it.** An office register is arguably institution-wide by nature.
Staff may legitimately need to see the organisational structure — to read a
hierarchy, or to pick a transfer destination — without being able to act on any
of it. Fineract permits the read, so no boundary is crossed.
- **Scope it.** Every other list this user sees is scoped to their subtree,
so the Offices screen quietly behaves unlike the rest of the application. If a
deployment treats its branch structure as sensitive, this discloses it to every
reader.
The asymmetry is recorded as an assertion pair and a comment in
`e2e/rbac-office-scoped-user.spec.ts` rather than asserted away, so whichever
way this is decided the spec documents the intent rather than freezing an
accident.
Note this is about *visibility of the list*, not about what can be changed:
the edit control is gated on `UPDATE_OFFICE` (#657), and Fineract refuses the
`PUT` regardless — see #663 and `security.md`.
Related: #663.
--
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]
