SUMMARY In ledger view, a full category name (including parents) should be shown. This is because multiple accounts can bear the same name, which is confusing to a user. The only way to show a full account hierarchy is by editing a transaction (which requires confirming a warning dialog if it had been previously reconciled) and then dropping down the list to show the category/account tree. This is especially challenging if the same account names exist in both Categories and Accounts. STEPS TO REPRODUCE 1. Assign a transaction to an account/category deeper in their hierarchies 2. Possibly also reconcile it OBSERVED RESULT You can't tell the account's/category's parent(s) from glancing at the transaction details in the ledger. EXPECTED RESULT You should be able to tell that a) transaction is assigned to an account/category b) their parents from just looking at the transaction details.
The full name is shown in the transaction form and also if you turn on the 'ledger lens' feature in the setttings. For split transactions, if you hover the mouse over the text 'split transaction' the tooltip also shows full account/category names. I don't see what exactly is missing here.
Created attachment 141242 [details] macOS example OK, so in order to see the split contents, one has to: 1) Enable the "Ledger lens", which is not enabled by default 2) However over the "split transaction" text and wait a bit until the list is shown Splitting transactions is a core functionality of double-ledger bookkeeping software, so a modern UX guidelines in this case would dictate that the split contents should be visible to users without extra non-intuitive hops. Right now not only a user has to enable a non-default feature that is named ambiguously, then also have to "bump" into that information by accident, because the nature of a tooltip is so that it's not immediately known to a user that an information would be presented such way until they first see it. Most users expect them to explain the feature/checkbox/radio button etc. under a cursor, not to present extra information. So, in other words, this is not something majority of users will figure out by their own and will lead to frustration and support requests. Last, not least, tooltips simply don't exist on mobile/touch operated platforms, so that information would be unavailable there. All of the above is why the modern UX/UI dictates that tooltips should generally speaking *not* be used for such purposes. And because of the mobile/touch platforms, the modern UI should ideally getaway without using them at all, by making the UI self-explanatory and having the whatever tooltip information would be directly visible on the screen as a subscript of an option (see macOS screenshot example attached).
Thomas, this was actually supposed to go as a comment under a different UI issue, although some of it applies here nonetheless.