You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fineract.apache.org by "opensource-joe (via GitHub)" <gi...@apache.org> on 2026/08/15 17:56:51 UTC
[I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
opensource-joe opened a new issue, #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355
## What is wrong
285 routes across 21 feature route files still inherit their tab title from the section above them, so whole areas of the app share one title.
This is the follow-up I offered in [#339](https://github.com/apache/fineract-backoffice-ui/pull/339), which closed #250. That PR added `TranslatedTitleStrategy`, titled the 25 sections in `app.routes.ts`, and refined `groups.routes.ts` as the worked example. Angular's `buildTitle` walks up to the nearest titled ancestor, so every page already has a reasonable title and nothing is broken. But inheritance means every page under a section reads the same:
```
Products · Fineract <- product list
Products · Fineract <- create loan product
Products · Fineract <- edit charge
Products · Fineract <- fixed deposit product detail
```
65 routes under `products` resolve to that one title. 46 under `system`, 25 under `accounting`, 24 under `loans`.
## Business value
The same two reasons #250 gave, neither of which inheritance solves.
Back-office work is multi-tab work. Someone comparing two loan products, or checking an accounting rule while editing a charge, has a tab strip that says "Products, Products, Accounting, Products". The title is what makes a tab findable, and at section granularity it is not doing that. Browser history and bookmarks have the same problem: a bookmarked charge screen and a bookmarked product list are indistinguishable in the bookmark list.
And the non-visual case from #250 still stands. The document title is announced on navigation and is the main signal that the page changed in a single-page app. Announcing "Products" on every navigation within products is close to announcing nothing: the user learns that they are still where they were, which they knew.
## Finding them
Measured against `main` at 98770c4:
```
route files: 23
refined (any title:) 2 app.routes.ts, groups.routes.ts
UNREFINED 21
route entries total: 324
route entries in unrefined: 285
```
```bash
python3 - <<'PY'
import pathlib, re
PATH, TITLE = re.compile(r"\bpath\s*:"), re.compile(r"\btitle\s*:")
for p in sorted(pathlib.Path('src').rglob('*.routes.ts')):
s = p.read_text(errors='ignore')
n, t = len(PATH.findall(s)), len(TITLE.findall(s))
if n and not t:
print('%3d routes %s' % (n, p))
PY
```
Largest first: `products` (65), `system` (46), `accounting` (25), `loans` (24), `clients` (21), `organization` (19), `working-capital` (15), then `campaigns`, `security`, `spm`, `tellers` (7 each), `admin`, `centers`, `transfers` (6), `interop`, `settings` (5), `calendars`, `meetings` (4), `fintech`, `reporting`, `tasks` (2).
One correction to my own note in #339: I said 22 route files there. It is 21 against current `main`.
## Scope
Add `title:` to the routes in each file, as translation keys, the way `groups.routes.ts` does. `check-translations.mjs` already understands the route-title form, so a wrong key is a build failure rather than a silent fallback.
This is deliberately 21 independent pieces of work. No file depends on another, each is small, and each is reviewable on its own, which is what #250 asked for. That also makes it good first-issue material: anyone can take one file without coordinating.
So rather than assume it: **would you prefer one PR per feature area, a few grouped PRs, or one PR for all 21?** One PR touching 21 files is a large diff of very repetitive changes, and 21 PRs is a lot of review overhead in the other direction. My guess is that grouping by size, with the four big ones (`products`, `system`, `accounting`, `loans`) separate and the rest together, is the least review burden, but this is your call and I will follow whatever you prefer.
I am happy to leave some of these unclaimed for other contributors if you would rather use them that way. Say the word and I will take only the four large ones, or none.
--
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] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5312366326
@opensource-joe For
> One thing I found and did not fix
> Three list components in products carry hardcoded English headings rather than translation keys: fixed-deposits-list, recurring-deposits-list and share-accounts-list render title="Fixed Deposit Accounts" and similar. check-translations.mjs cannot catch this, because it only validates strings that are already keys. It is a real i18n bug but not a titling one, so those three routes take the correct nav.* keys and I have left the headings alone. Happy to file it separately if you want it tracked.
>
> Also, and much smaller: products/recurring and products/share are the product lists but render nav.recurringDeposits and nav.shares, which are the account labels. Their titles use nav.recurringDepositProducts and nav.shareProducts, so on those two the tab is right and the on-screen heading is wrong.
You can create new issue for that
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "opensource-joe (via GitHub)" <gi...@apache.org>.
opensource-joe commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5317764019
@Aman-Mittal Filed as #388, both items in one issue.
It grew a little in the writing: the hardcoded English headings are **14 across 11 files**, not the three in `products` I had found. Same class of bug, just wider than the sample I hit. Full table with file and line is in the issue.
Also noted there why `check-translations.mjs` cannot catch these, and left the question of whether the guard should grow a rule for it open rather than assuming.
I offered to take both but left them unclaimed, in case you would rather item 2 went to a newcomer. It is two lines with all four keys already present, which is about as clean a first patch as this repo has right now.
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal closed issue #355: 285 routes in 21 feature files still inherit their tab title from the section above them
URL: https://github.com/apache/fineract-backoffice-ui/issues/355
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "opensource-joe (via GitHub)" <gi...@apache.org>.
opensource-joe commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5305365059
@Aman-Mittal thank you, that split is clearer than what I proposed and the reason for landing one file first makes sense: the cost here is the key naming, not the diff.
One thing in your answer I cannot resolve on my own, and I would rather ask than pick.
You listed `clients` (21 routes) as PR 1, on its own, **because** it settles the naming convention. Then under what to leave you said to take `products` and `system` and leave `accounting`, `loans`, **`clients`** and the 16 small files as newcomer work, "with the convention already settled by your first PR."
If `clients` is left for a newcomer, then my first PR is `products`, and the convention gets settled by a 65-route file rather than the small one you picked for that purpose. If `clients` is mine, then it is not available to a newcomer. Both readings are defensible and they lead to different first PRs.
My guess is the first: I take `clients`, `products` and `system`, and `accounting`, `loans` and the 16 small files stay open, since that keeps the convention-setting PR small and still leaves six of the eight pieces for other people. But it is your review time and your contributor queue, so I will do whichever you say, including dropping to just `products` and `system` and leaving `clients` open with the convention written into #355 instead.
Either way I will write the two decisions you asked for back into #355 once the first one lands: whether these reuse existing `nav.*` / `FEATURE.TITLE` keys or get new ones, and what `view/:id` and `edit/:id` routes are titled, given Angular's static `title` cannot interpolate the record. And I will leave `products.routes.ts` flat as you asked; the nesting idea is not folded into this.
No rush on this one, it is not blocking anything. #354 is up as #365 whenever you get to it.
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "opensource-joe (via GitHub)" <gi...@apache.org>.
opensource-joe commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5303519893
@Aman-Mittal flagging this one too, as the other half of what #339 left behind. #250 scoped the per-feature refinement as newcomer tasks, and this is what is actually left of it now that `TranslatedTitleStrategy` and the 25 section titles have landed.
Nothing here is broken, so there is no urgency. Inheritance means every page already gets a sensible title. It is just that 65 routes under `products` all get the same one.
Two things I would rather ask than assume:
1. **How would you like it split?** One PR for all 21 files is a large and very repetitive diff. 21 PRs is a lot of review. My guess is the four big ones separately and the rest grouped, but it is your review time, so you decide.
2. **How many should I leave alone?** These are genuinely good first issues and I do not want to take work that is more useful sitting there for someone new. Say the word and I will take only the four large files, or none at all, and just leave the list.
Also a correction to myself: #339's description said 22 route files remained. Measured against current `main` it is 21.
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "opensource-joe (via GitHub)" <gi...@apache.org>.
opensource-joe commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5311998215
@Aman-Mittal Writing the two decisions back as promised, now that #380 is up and I have taken `products` and `system` far enough to know whether the convention survives contact with them. It mostly does, with one correction I would rather make myself than have found in review.
Grounded in 135 routes across the three files, not in the 21 that settled it.
## Decision 1: existing keys or new ones
**Take the key the page already uses for its own visible heading.** Not a new key, and not the `nav.*` entry, except in the two cases below.
- The **section root** (`path: ''`) restates the `nav.*` key its section entry uses in `app.routes.ts`, so the file reads on its own rather than relying on inheritance. `clients` does this with `nav.clients`, as `groups` already did with `nav.groups`.
- Everything else takes its page's heading key: `CLIENTS.ADD_IDENTIFIER`, `SYSTEM.EDIT_DATA_TABLE`, `TAX_GROUPS.CREATE`, and so on.
**Correction to what I wrote in #380.** That description says the convention needs no new translation keys, and offers it as an argument for the convention. That was true of `clients` and it is not true in general, so please do not hold me to it as stated.
The accurate version is a rule about **route shapes**, not about feature areas:
| File | Routes | New keys needed |
|---|---|---|
| `clients` | 21 | 0 |
| `system` | 49 | 0 |
| `products` | 65 | 6 |
`system` is the larger file and needed nothing. `products` needed six. The difference is not luck: **`system` has no `view/:id` route at all**, and `products` has five. Every screen in `system` is a list, a configuration page or a create/edit form, and each of those already renders its own name, so rule 2 always finds a key. A record view is the one shape where the visible heading is the *record* rather than the *screen*, which is exactly when there is no key to reuse.
So: **a file needs new keys if and only if it contains routes whose heading is bound at runtime.** Anyone picking up a file can tell in advance which they have.
## Decision 2: `view/:id`, `edit/:id`, and anything else the router parameterises
`edit/:id` is not a special case at all. The form already renders "Edit X" as its heading, so rule 2 applies unchanged: `CLIENTS.EDIT_CLIENT`, `TAX_COMPONENTS.EDIT`, `SHARE_ACCOUNTS.EDIT`. Same for `create`.
`view/:id` is the real case, and it is worth being explicit because the obvious reading of rule 2 gives the wrong answer.
Angular's static `title` cannot interpolate the record, so the route takes **a generic key naming the screen type, and it must be specific to the entity**. The trap is that these pages usually render `COMMON.DETAILS` or `COMMON.OVERVIEW` in the card above the record's name, so following rule 2 literally is possible and produces:
```
Details · Fineract <- loan product
Details · Fineract <- savings account
Details · Fineract <- fixed deposit account
Details · Fineract <- recurring deposit account
```
which is this issue's own problem, one level down. `products` is where that shows up, because it has five record views in one file.
What #380 and the two branches do instead:
| Route | Title | |
|---|---|---|
| `clients/view/:id` | `CLIENTS.DETAILS` | existed |
| `products/loan/view/:id` | `nav.loanProductDetails` | existed |
| `products/savings-accounts/view/:id` | `SAVINGS.ACCOUNT_DETAILS` | new |
| `products/fixed-deposits/view/:id` | `FIXED_DEPOSITS.ACCOUNT_DETAILS` | new |
| `products/recurring-deposits/view/:id` | `RECURRING_DEPOSITS.ACCOUNT_DETAILS` | new |
| `products/shares/view/:id` | `SHARE_ACCOUNTS.ACCOUNT_DETAILS` | new |
Same treatment for any route whose heading is bound at runtime even when it is not a `view/:id`. Two examples already hit:
- `products/:accountType/:accountId/action/:command` picks its heading from a command-to-key map, so it takes a new `ACTIONS.ACCOUNT_ACTION`.
- `system/codes/:codeId/values` binds `[title]="codeName()"`, the code's own name, so it takes the existing generic `CODE_VALUES.TITLE`.
**The test that keeps this honest.** Both branches carry a spec asserting that **no two routes in a file share a title**. That is the one that fails if someone later takes the `COMMON.DETAILS` shortcut, and it is verified in the failing direction, not just the passing one. I would suggest every file's PR carries it, since a titling change that leaves two tabs identical has not done its job.
## The `tellers` case you asked me to cover
`tellers/:tellerId/cashiers/:cashierId/transactions/:command`.
The good news is that **the depth is not the problem and needs no special rule.** Three levels of parameter title exactly like one. Rule 2 reads the page's heading and nothing about nesting enters into it.
The `:command` segment is the problem, and it comes with a collision that is easy to walk into:
- `.../transactions` renders `TELLERS.CASHIER_TRANSACTIONS` ("Cashier Transactions"). Rule 2, straightforward.
- `.../transactions/:command` picks `TELLERS.ALLOCATE_CASH` or `TELLERS.SETTLE_CASH` depending on the parameter, so no static title can name it.
The tempting move is to give the second one `TELLERS.CASHIER_TRANSACTIONS` too, since it is the nearest generic. That collides with the list route and the uniqueness test above will fail it. It needs **one new key**, singular, something like `TELLERS.CASHIER_TRANSACTION` ("Cashier Transaction"). That is the whole of the special handling that file needs, and it is the only new key in it.
## Which of the remaining files this affects
Rough count of routes whose title cannot come straight from a heading, so whoever picks a file knows what they are in for:
- **Need at least one new key:** `accounting`, `loans`, `centers`, `organization`, `working-capital`, `calendars`, `meetings`, `fintech`, `tellers`.
- **Should need none:** `admin`, `campaigns`, `interop`, `reporting`, `security`, `settings`, `spm`, `tasks`, `transfers`.
Worth checking rather than trusting, since I derived it by pattern-matching route paths rather than by reading all sixteen files.
## One thing I found and did not fix
Three list components in `products` carry hardcoded English headings rather than translation keys: `fixed-deposits-list`, `recurring-deposits-list` and `share-accounts-list` render `title="Fixed Deposit Accounts"` and similar. `check-translations.mjs` cannot catch this, because it only validates strings that are already keys. It is a real i18n bug but not a titling one, so those three routes take the correct `nav.*` keys and I have left the headings alone. Happy to file it separately if you want it tracked.
Also, and much smaller: `products/recurring` and `products/share` are the *product* lists but render `nav.recurringDeposits` and `nav.shares`, which are the *account* labels. Their titles use `nav.recurringDepositProducts` and `nav.shareProducts`, so on those two the tab is right and the on-screen heading is wrong.
---
**Status.** `clients` merged as #380. `products` is now up as **#382** and `system` as **#383**, both applying the convention above. `accounting`, `loans` and the 16 small files remain open for newcomers, with the three decisions here settled so nobody has to re-derive them.
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5306028456
You are right that those two paragraphs contradict each other, and your reading is the one I meant. Take **clients, products and system**. `accounting`, `loans` and the 16 small files stay open.
Clients specifically, rather than something smaller, because it is the only mid-size file that carries every shape the convention has to answer: empty path, `create`, `edit/:id`, `view/:id`, and two-level nested sub-resources (`:clientId/identifiers/edit/:id`, `:clientId/collaterals/create`). The small files mostly do not — `settings` is five flat paths, `campaigns` is list/create/edit per channel. If the convention gets settled on one of those, the nested sub-resource case is still unanswered when 18 later PRs hit it, and that is exactly the one people will answer differently from each other. So clients is not just a small file for the purpose, it is the one that forces the decisions.
One extra case to cover while you are writing those decisions back: `tellers` goes a level deeper than clients does — `:tellerId/cashiers/:cashierId/transactions/:command`. Whoever picks that file up will be the only person to hit three levels plus a `:command` segment, so a line on it in #355 will save them guessing.
That still leaves 18 of the 21 files and a bit over half the routes for other people, which is more than enough queue.
Thanks for leaving `products.routes.ts` flat. I will get to #365.
--
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
Re: [I] 285 routes in 21 feature files still inherit their tab title from the section above them [fineract-backoffice-ui]
Posted by "Aman-Mittal (via GitHub)" <gi...@apache.org>.
Aman-Mittal commented on issue #355:
URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5303647864
Counts confirm on my side too: 21 files, 285 routes, `groups.routes.ts` the only one already done. No need to flag the 22 → 21 thing further.
**Split:** five PRs, not 21 and not one.
1. `clients` (21 routes) — first, on its own, because it settles the naming convention.
2. `products` (65)
3. `system` (46)
4. `accounting` (25) + `loans` (24)
5. the remaining 16 files (~104 routes) as one PR
The reason for landing clients alone first: the review cost here is not the diff, it is the key naming, and that decision is made once. Two things I want pinned down in that PR and written into this issue afterwards, so nobody has to re-derive them:
- whether these reuse existing `nav.*` / `FEATURE.TITLE` keys or get new ones
- what `view/:id` and `edit/:id` routes are titled. Angular's static `title` cannot interpolate the record, so these get a generic name. Say so explicitly, or 21 files will each invent something different.
**What to leave:** take `products` and `system`. 111 near-identical title lines is drudgery, not a first contribution, and nobody new is going to enjoy it. Leave `accounting`, `loans`, `clients` and the 16 small files as newcomer work — with the convention already settled by your first PR, each of those is a genuinely good first issue rather than a guessing game.
One thing not to do: `products.routes.ts` is 65 flat routes with no nesting, and it is tempting to restructure it into children so one parent title covers each entity's list/create/edit triple. Please don't fold that into this. It changes matching and guard behaviour, and it belongs in its own PR if it is worth doing at all.
--
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