Aman-Mittal opened a new pull request, #356:
URL: https://github.com/apache/fineract-backoffice-ui/pull/356
Fineract serves `/v1/internal/**` only when the backend runs with its
**`test` Spring profile**, which upstream states must not be enabled in
production. Six screens depend on those endpoints and were routed *and* listed
in the navigation — so on a normal deployment a user could reach them and every
action returned 404.
Verified against a running instance, 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 spec agrees — it describes several of them as internal, and the
working-capital ones as *"(testing only)"*.
## Gated, not deleted
Against a test instance these are legitimate tooling, and deletion is not
reversible. `developerToolsEnabled` in `config.json` exposes them and is
**off** unless a deployment opts in — a runtime flag, so a QA environment needs
no rebuild.
Enforced in two places, because hiding a nav entry leaves the route
reachable by URL:
- `NavItemConfig.developerTool` hides the entry
- `developerToolsGuard` (`CanMatch`) stops the route matching at all
**The developer-tool check sits *before* the `rbacEnabled` short-circuit**,
for the same reason the existing `hidden` check does: turning RBAC off means
"show this user everything they may reach", not "expose endpoints this
deployment cannot serve". There's a test for exactly that.
| Screen | Treatment |
|---|---|
| Admin → COB Tools | Gated (wholly internal) |
| Admin → WC COB Tools | Gated (wholly internal) |
| Admin → External Events *(internal log)* | Gated (wholly internal) |
| Admin → Progressive Loan Model | Gated (wholly internal) |
| Working Capital → Account Locks | Gated (wholly internal) |
| **Loans → Account Locks** | **Screen kept** — see below |
**Loans → Account Locks keeps its screen.** Its listing uses the supported
`/v1/loans/locked`; only the *place-lock* action posts to an internal endpoint,
so only that half is gated. I initially gated the whole route and corrected it
— removing it would have removed working, supported functionality, which is the
opposite of the goal.
`System → External Events` (`/v1/externalevents/configuration`) is a
**different, supported screen** and is untouched. The two are easy to confuse.
## The CI guard
`scripts/check-internal-endpoints.mjs` pins the list so a new dependency on
a test-only endpoint has to be deliberate.
It derives the internal operations from the generated client's `@endpoint`
tags rather than a hardcoded list of names, so it follows the spec when the
spec changes. It fails on **both**:
- a new ungated reference, and
- an allow-list entry that no longer calls an internal endpoint — a stale
entry is as misleading as a missing one.
Both failure modes were verified by introducing them:
```
✖ Files calling a /v1/internal/ endpoint without approval:
src/app/features/system/external-events/external-events.component.ts
GET /v1/internal/externalevents → exit 1
✖ Allow-list entries that no longer call an internal endpoint:
src/app/features/does-not-exist.component.ts → exit 1
```
It also fails loudly if it finds *no* internal operations at all, rather
than passing silently — that would mean either the spec dropped them (worth
revisiting these screens) or the client layout changed.
Wired into the CI job that already runs the i18n and icon checks.
## Testing
- **952 unit specs.** New: the screens stay hidden by default, appear when a
deployment opts in, and stay hidden when RBAC is off.
- Two existing nav specs asserted the previous behaviour
(`/admin/wc-cob-tools` and `/working-capital/loans/account-locks` visible as
"ungated siblings"). They are updated to record the new rule **with a comment
explaining the reason differs from permission gating** — not relaxed.
- `provideTestConfig` implements the new accessor, so the double keeps
matching the real service.
- `lint`, `format:check`, `i18n:check`, `check:icons`, `check-license.sh`,
`build`, and Apache RAT (666 approved, 0 unapproved) all clean.
Follows the legacy-functionality audit. The audit recommended this as a
**PMC decision**; gating rather than removing keeps that decision open — if the
PMC prefers exclusion, the routes and components can come out later without
anything else changing.
--
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]
