You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "Aman-Mittal (via GitHub)" <gi...@apache.org> on 2026/10/02 12:09:21 UTC

[I] Office Transactions: the route declares READ_OFFICETRANSACTION, but the screen cannot load without READ_OFFICE [fineract-backoffice-ui]

Aman-Mittal opened a new issue, #665:
URL: https://github.com/apache/fineract-backoffice-ui/issues/665

   `organization/office-transactions` declares a single permission:
   
   ```ts
   data: { permissions: 'READ_OFFICETRANSACTION' },
   ```
   
   The permission guard admits a user holding exactly that, the nav entry is shown to them, and then Fineract refuses the list:
   
   ```
   GET /officetransactions -> 403
   {"userMessageGlobalisationCode":"error.msg.not.authorized",
    "errors":[{"defaultUserMessage":"User has no authority to READ offices", ...}]}
   ```
   
   Verified with a seeded user holding only `READ_OFFICETRANSACTION`: `GET /officetransactions` is 403 and `GET /offices` is 403. Adding `READ_OFFICE` to the same role makes the screen load.
   
   So a user who holds precisely what the route asks for reaches a screen that can never work. Every other screen's declared permission is sufficient for the screen to function.
   
   ## Options
   
   1. **Declare both codes** with AND semantics. The guard already supports `permissionsMatchAll`, and this would be its first production use — it exists in the guard and on no route today. The nav entry would then be hidden from a user who cannot use the screen, which is the behaviour the rest of the navigation has.
   2. **Leave the route and accept the refusal**, now that the screen reports it rather than showing an empty table (#660 gave it an error state, so the refusal is at least visible and distinguished from a load failure).
   
   Option 1 looks right, but it changes who sees a nav entry, so it is a product decision rather than a bug fix and is deliberately not folded into the error-state change. `check:route-permissions` would also need to accept an array here.
   
   ## Related platform defect — not a UI issue
   
   While covering this screen it emerged that office transactions **cannot be created at all** against `apache/fineract:latest`:
   
   ```
   POST /officetransactions -> 403
   ERROR: column "currency_multiplesof" of relation "m_office_transaction" does not exist
   ```
   
   Per `CONTRIBUTING.md` that is a platform bug and belongs in the [ASF Jira project](https://issues.apache.org/jira/projects/FINERACT) for apache/fineract — Fineract returned a 4xx with a `defaultUserMessage` explaining why — not here. It is recorded only because it has a consequence for this repository: the delete action's permission gating on this screen cannot be covered by a backend e2e spec, since no transaction can be seeded to render a row. That gating is covered by the directive's unit tests instead.
   


-- 
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: issues-unsubscribe@fineract.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Office Transactions: the route declares READ_OFFICETRANSACTION, but the screen cannot load without READ_OFFICE [fineract-backoffice-ui]

Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal closed issue #665: Office Transactions: the route declares READ_OFFICETRANSACTION, but the screen cannot load without READ_OFFICE
URL: https://github.com/apache/fineract-backoffice-ui/issues/665


-- 
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: issues-unsubscribe@fineract.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org