Aman-Mittal opened a new issue, #357:
URL: https://github.com/apache/fineract-backoffice-ui/issues/357
## Business value
A back-office user can open six screens from the navigation and every button
on them fails. Nothing explains why, because nothing is wrong with the user,
their permissions, or their data — the endpoints those screens call are simply
not served by a production Fineract.
The cost is not only the wasted click. A screen that fails silently teaches
an operator that the application is unreliable, and it generates support
traffic that cannot be resolved by anyone in the branch: the answer is "that
page cannot work here", which no error message says. For the **first release**
of this application, shipping menu entries that cannot function is the kind of
first impression that is expensive to undo.
There is also a real need behind these screens. They are useful tooling
against a test instance — COB fast-forward, loan reprocessing, the
progressive-loan schedule model. The goal is to keep them available where they
work, not to lose them.
## What is wrong
Fineract serves `/v1/internal/**` only when the backend runs with its
**`test` Spring profile**. Upstream states that profile must not be enabled in
production. Six UI screens depend on those endpoints, and all six are routed
and present in the navigation.
Verified against a running Fineract, using the same credentials the passing
e2e suite uses:
```
GET /v1/internal/externalevents → 404
GET /v1/internal/cob/partitions/10 → 404
GET /v1/internal/loan/progressive/1/model → 404
```
The OpenAPI spec agrees. Several of these operations describe themselves as
internal, and the working-capital ones say so outright:
```
POST /v1/internal/working-capital-loans/{loanId}/activate
"Activate a Working Capital Loan (testing only)"
POST /v1/internal/working-capital-loans/{loanId}/amortization-schedule
"Generate and save Projected Amortization Schedule (testing)"
```
These operations are **not deprecated and not removed** — they are current
and documented. They are simply unavailable on the deployment a real user runs
against, which is a different problem and needs a different answer.
## Affected screens
| Screen | Files | Dependence |
|---|---|---|
| Admin → COB Tools | `features/admin/cob-tools/` | Wholly |
| Admin → WC COB Tools | `features/admin/wc-cob-tools/` | Wholly |
| Admin → External Events *(internal log)* |
`features/admin/external-events/` | Wholly |
| Admin → Progressive Loan Model | `features/admin/progressive-loan/` |
Wholly |
| Working Capital → Account Locks |
`features/working-capital/loans/wc-account-lock/` | Wholly |
| Loans → Account Locks | `features/loans/loan-account-lock/` | **Partly** —
the listing uses the supported `/v1/loans/locked`; only the place-lock action
is internal |
**Do not confuse this with System → External Events**
(`/v1/externalevents/configuration`), which is a separate, fully supported
screen and must keep working.
## What to build
Expose these behind an explicit, off-by-default deployment flag rather than
removing them, so they remain usable against a test instance:
- A runtime flag in `config.json` (defaulting to off, including when the key
is absent, so existing deployments do not inherit the screens).
- Hide the navigation entries when it is off.
- Guard the routes too — hiding a nav entry leaves the path reachable by
URL, which is not a gate.
- For **Loans → Account Locks**, gate only the place-lock action. The
listing is supported and must stay.
### Two things to get right
1. **Order the check before the RBAC short-circuit.** `rbacEnabled: false`
currently means "show this user everything", and a naive implementation will
expose the developer tools in exactly the deployments least equipped to explain
them. Turning RBAC off answers "what may this user reach", not "what can this
deployment serve".
2. **Pin the list in CI.** Without a check, the next screen built on an
internal endpoint arrives unnoticed. Derive the set of internal operations from
the generated client's `@endpoint` tags rather than a hardcoded list of method
names, so it follows the spec as the spec changes.
## Testing
- **Unit:** the screens are hidden by default; visible when a deployment
opts in; still hidden when RBAC is disabled.
- **Unit:** the route guard refuses the path when the flag is off.
- **Unit:** the Loans → Account Locks listing still renders with the flag
off, and the place-lock control does not.
- **CI check:** verify it fails both on a new ungated reference *and* on a
stale allow-list entry — a guard nobody has tried to break is not yet known to
work.
Note that two existing navigation specs assert the current behaviour
(`/admin/wc-cob-tools` and `/working-capital/loans/account-locks` visible as
ungated siblings). They should be updated to record the new rule, not relaxed.
## Scope
In scope: the deployment flag, navigation and route gating for the six
screens, the partial gating of Loans → Account Locks, and the CI check.
Out of scope: removing the screens or their components — whether this
application should ship developer tooling at all is a PMC decision, and gating
deliberately leaves that open. Also out of scope: `System → External Events`,
which is supported.
## Getting started
- `src/app/core/services/config.service.ts` — where runtime configuration
lives; `rbacEnabled` is the pattern to follow
- `src/app/core/services/navigation-config.service.ts` — nav filtering,
including the `hidden` check that is already ordered before the RBAC
short-circuit for the same reason
- `src/app/core/guards/` — existing guard for reference
- `npm test`, `npm run lint`, `npm run build`
--
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]
