Hello dev team: I installed v4.0 today. This bug occurs in the account register. Typing the account number into the account field and then pressing the [TAB] key should select the account. This fails. Please review and advise. Regards, Jeff Woehler
Do you mean (in English) the Account Code? Maybe it's called Account Number in some other language... Searching for the Account Code in the help and guide doesn't find anything that says you can type Accounts Codes to find them... But it does work in my old GnuCash 3.4 Linux system. You type in the Account Code in the register Account field, (nothing shows as you type), then hit Tab and the account with that Account Code is put into the field. I suspect this is a regression caused by https://github.com/Gnucash/gnucash/pull/664 Implement type-ahead account name completion
Chris, Did you try this on Windows ? Just tried this on my Linux VM, typed in to a register 'Account' field an account code, pressed tab, and the correct account name is added to the account field. Typing an incorrect account number results in a dialog advising 'The account 12324 does not exist. Would you like to create it'.
Bob, yes I tested in Windows 10.
bug 797856 reports the same problem but on Linux, or more specifically on Fedora 32; the reporter there says that it works for him in the Flatpak build. FWIW it works correctly on MacOS.
I don't know if this helps or is related to account code, but I've noticed on windows also that occasionally if I tab into the account field and start typing very quickly, it doesn't always start populating accounts. When it does this, I can do shift tab, then tab again to go in and usually works the second time. I can't say I have found a consistent way to replicate the problem, but speed seems to be involved. I wonder if it's similar where the account filter just doesn't work at sometimes, whether it's an account code or account name. I haven't opened a separate but only because I can't recreate it reliably.
Is this related to bug 797856 at all?
(In reply to Matt Forbis from comment #6) > Is this related to bug 797856 at all? See comment 4. ;-)
(In reply to John Ralls from comment #7) > (In reply to Matt Forbis from comment #6) > > Is this related to bug 797856 at all? > > See comment 4. ;-) My bad. Ignore my stupidity.
I just tested on Windows 10. Worked fine. Chris Good, did you test 4.0 on Win10 and have it fail? Jeff Woehler, you said only that it fails. How does it fail? My first suspicion for irreproduceable results is locale, so Jeff Woehler what are your Region & Language settings?
John Ralls, I thought I had tested in Windows 10 and it didn't work, but I just tested again Win10, GnuCash 4.0, and it does work for me now. I'm not sure I remember correctly it failing before as I've been super busy last few days...
Thanks for taking a look. I'm on Windows 10, GnuCash 4.0. Matt - I tested today with waiting a moment before typing. This doesn't seem to have an different effect for me. Issue still occurs. John - here are more details on how it fails: When I first tab into an empty Account field the Account selector dropdown is not visible. As I type the account number "64508" the Account dropdown is displayed and the first account is selected by default. When I click tab that selected account (top of the list) is chosen and placed into the Account field. Notes on my Region and Language settings: Country: United States Day of the week: Sunday Short date: yyyy-MM-dd (2020-07-17) Long date: dddd, dd MMMM yy (Friday, 17 July 2020) Short time: HH:mm (22:57) Long time: HH:mm:ss (22:57:01) Decimal symbol: . Digit grouping: , Negative symbol: - Final note: I use '.' as my Account separator character. In Edit > Preferences > Accounts, I have the word 'period'. Anything else I can help with, let me know. Appreciate the help. Regards, Jeff
Do you have one or more accounts that include 64508 in their names?
I do not.
I should have noted that the numbers need not be contiguous, though I think that hey should be in order. Otherwise there should be no match at all. What are the fully-qualified account names that match 64508?
I have tried again with Windows 10 but still can not reproduce. Would you be willing to export your account tree, 'File->Export->Account Tree to CSV' and attach to this bug report. If you Do, PLEASE check the CSV file for and private data, remove or obfuscate.
Created attachment 373792 [details] Screenshot of Expenses Tree with Sales Tax account selected I'll start with a screenshot. If necessary, I'll do what it takes to reproduce with a smaller account list and send you that as time allows. Regards, Jeff
I'm afraid the screenshot isn't helpful because it doesn't show what accounts match when you enter 64508. Is it the whole tree? If not, what accounts match? And just to be clear, you're typing *only* 64508, right?
Created attachment 373794 [details] Account Tree for testing issue I've attached my account tree, removing only a few personal accounts and leaving the rest as-is. I can still reproduce the issue with this account list. Regards, Jeff
Created attachment 373795 [details] Screencast video of issue reproduced Also attached is a video screencast of the problem so that we're both seeing and understanding the same thing. Hope this helps. Anything else I can do, let me know. Regards, Jeff
It's the account separator. The typeahead search uses regular expressions that include the separator, and '.' is the regular expression character that means "match any character". Fixed in git for tomorrow's nightly and 4.1.
Great news. Thanks for the update.
*** Bug 797864 has been marked as a duplicate of this bug. ***
Confirmed fixed - thanks for the help. And... really slick account name selection in the new release. Nice job!
