Aman-Mittal opened a new pull request, #523:
URL: https://github.com/apache/fineract-backoffice-ui/pull/523
Closes #487.
## What it does
`branding/config.json` and `branding/i18n/{lang}.json` were requested on
every load. They are absent on every default install — the documented, correct
state — so a fresh deployment reported two 404s in the browser console on every
route.
The application already declined to *report* those failures: both fetches
carry `skipErrorToast` and both resolve to `{}`. That is as far as this side
can reach. A 404 is a network-level event the browser writes regardless, so the
only way for a supported configuration to stop looking like a misconfiguration
is not to make the request.
## The flag, and where it has to live
`brandingOverlayEnabled` gates both fetches. It cannot live in the overlay
itself — a file cannot announce its own absence — so it belongs in the layer
below.
**The container entrypoint sets it for you**, by looking for the directory
the deployer already declared with the `COPY branding/ ...` line in
`DOCS/CUSTOMIZATION.md`. There is nothing new to remember, and it satisfies
that heredoc's own stated rule:
> the rule for this heredoc is narrow: it carries only what the *container
environment* is the right source for
Whether this image carries a branding overlay is a fact about the
container's filesystem, which is exactly that. A deployment serving `dist/`
from its own web server sets it in `config.json` alongside `fineractApiUrl`;
that case is documented.
The flag also makes a distinction the old code could not: "no overlay
configured" versus "overlay configured but misdeployed". The second is a real
error a deployer wants to see, and it still surfaces — a declared overlay that
404s is tolerated in the merge but is no longer indistinguishable from the
ordinary case.
## Verified against a running app
Console across `/dashboard`, `/clients`, `/loans`, `/notifications`,
capturing every line.
Before, on `main`:
```
failed net::ERR_CONNECTION_REFUSED http://localhost:4201/remoteEntry.json
http 404 /branding/config.json
http 404 /branding/i18n/en.json
```
After, on this branch:
```
failed net::ERR_CONNECTION_REFUSED http://localhost:4201/remoteEntry.json
```
What remains is the microfrontend remote, which is simply not running in a
plain `ng serve`.
And the positive path, with the flag on and a real overlay in place:
```
branding requests: 200 /branding/config.json?cb=... | 200
/branding/i18n/en.json
brand text: Any Community Bank
```
The overlay's `appName` renders and the language overlay is merged, so the
flag gates the probe without disabling the feature. The temporary overlay used
for that check was removed; `npm run check:branding-path` passes.
## One trap worth flagging in review
The loader resolves `ConfigService` **on use**, not as a field. Injecting it
at construction closes a cycle — `ConfigService` needs `HttpClient`, whose
`errorInterceptor` needs `I18N`, which needs the loader. Angular reports it as
NG0200 during bootstrap and the app renders nothing at all.
The unit tests do not catch that, because they provide `ConfigService`
directly. I found it by loading the application; `login.spec.ts` would have
caught it in CI. Worth knowing before anyone tidies that `inject(Injector)`
back into a field — the comment on it says so.
## Verification
| | |
|---|---|
| `npm run test:unit` | 237 files / 1427 tests, exit 0 |
| `TZ=America/New_York npm run test:unit` | 237 files / 1427 tests, exit 0 |
| `npm run build` | clean |
| `npm run lint` | clean |
| `bash scripts/check-license.sh` | clean |
| `node scripts/check-branding-path.mjs` | `public/branding/` is reserved
and empty |
| `bash -n deploy/entrypoint.sh` | clean |
New coverage: four cases on `ConfigService` for the probe (not declared,
declared off, declared on, declared but missing) and a new
`deployment-translate.loader.test.ts` with four more, including that the
overlay request is not issued when undeclared.
Rebased on `f18d9592`.
--
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]
