GNOME Bugzilla – Bug 604519
Document different Edit > Find... behaviour on Accounts Tab or account register tab
Last modified: 2018-06-29 22:31:48 UTC
I did Edit > Find... and entered a string which I know occurs in the description of some transactions, and it didn't find them. I opened the account containing the relevant transactions and then did it again, and it worked. I changed focus to a different account (but the other account was still open) and did the find again, and it once again didn't find the transactions. Is this change behavior? I would find that hard to believe in GnuCash 2.2.9, Edit > Find... does what I expect it to do -- searches all transactions, not just those in the current account. If this change is intentional, then there needs to also be a way to search all transactions, eh? Thanks.
Hm, seems to work for me with current trunk. Once it has been released, may you please check with GnuCash 2.3.9? Or better yet, compile from the svn's source. Thanks.
I am still having this problem with 2.3.13. Actually two problems: When I do Edit > Find... the option that is selected by default is "Refine current search", even though there is no current search. When I search for "Trustees" (after changing the option to "New search") while viewing the account in which one "The Trustees of Reservations" transaction occurs, the search results show only that transaction. When I then select the tab of another account with several other "Trustees of Reservations" transactions in it and again do a new search for "Trustees", the three matching transactions in that account are displayed in the search results, but the one matching transaction in the original account are not. These are serious problems which should block the release of GnuCash 2.4.
Just confirmed still broken in 2.3.15.
I've got to say that "search doesn't work" strikes me as a major defect, i.e., I'd categorize this as "major" rather than "normal". Also, looking at the descriptions of the bug importance field, it would seem that "blocker" was inappropriate (I thought it meant "release blocker", which it apparently doesn't), but I really don't think 2.4 should ship without this fixed.
I can't BELIEVE you shipped 2.4.0 with this still broken.
I just see your bugreport for the first time now. Sorry about not responding earlier. (In reply to comment #0) > Is this change behavior? I would find that hard to believe in GnuCash 2.2.9, > Edit > Find... does what I expect it to do -- searches all transactions, not > just those in the current account. If this change is intentional, then there > needs to also be a way to search all transactions, eh? As far as I know this is not a bug, but intended behaviour. If you start the search from the global Accounts Hierarchy page, it will search all your accounts. If you start from an account register, it will only search that account. I have dug around in the commit history and apparently this was changed in r17000 [1], which is more than 3 years old. This patch was never applied in the stable 2.2.x series of that time, only in the unstable development branch which eventually became 2.3.x and later 2.4.x. I think it is worth documenting this better, but since the change in behaviour was clearly intended, I don't think this should be considered a major bug. [1] http://svn.gnucash.org/trac/changeset/17000
By the way, adding a tip in our tip of the day list would definitely also be a good improvement.
In the current Help documentation for the 2.4.x Stable Release the Find transaction has become mis-filed in chapter 7 instead of Chapter 4 since it is now under the Edit menu. Additionally, it seems to be mostly documentation of the menu tree without good descriptions of usage, such as meanings of the terms used in the table of buttons, and specifically for Reconcile, are the choices mutually exclusive, so that only one choice is allowed per line in the top construction. Thus, to search for both Reconciled: is: not cleared and cleared but not reconciled or frozen or voided would require two lines of criteria? Or is it possible to toggle each choice button independently? If the latter, why is there a need for the is/is not choice? I am not able to figure out whether those buttons are simple buttons with an underlying mysterious set of rules or toggle buttons that seem to lose their status when the search button is clicked. I will volunteer to update the documentation and flesh it out some, but I am definitely not qualified to sort out the code for the buttons. If I were to update the documentation before the code behavior is resolved, there would be some side comments about indeterminate behavior. I am sure that your editorial board would need to review my output before it is accepted.
Hi David, (In reply to comment #8) > In the current Help documentation for the 2.4.x Stable Release the Find > transaction has become mis-filed in chapter 7 instead of Chapter 4 since it is > now under the Edit menu. That's a very good point. I'll work on moving that. > Additionally, it seems to be mostly documentation of the menu tree without good > descriptions of usage, such as meanings of the terms used in the table of Are you talking about chapter 4? It is an overview--I think it was kept brief on purpose. Most of GnuCash is thoroughly covered throughout the rest of the help manual and concepts guide, after all. > buttons, and specifically for Reconcile, are the choices mutually exclusive, so > that only one choice is allowed per line in the top construction. Thus, to > search for both Reconciled: is: not cleared and cleared but not reconciled or > frozen or voided would require two lines of criteria? Or is it possible to > toggle each choice button independently? If the latter, why is there a need > for the is/is not choice? > > I am not able to figure out whether those buttons are simple buttons with an > underlying mysterious set of rules or toggle buttons that seem to lose their > status when the search button is clicked. > > I will volunteer to update the documentation and flesh it out some, but I am > definitely not qualified to sort out the code for the buttons. If I were to > update the documentation before the code behavior is resolved, there would be > some side comments about indeterminate behavior. > > I am sure that your editorial board would need to review my output before it is > accepted. This is a good point. I'm asking the developers to clarify. And also opening a new bug # 691762 to tackle the question.
Created attachment 233563 [details] [review] Apply to gnucash-docs trunk
Created attachment 233564 [details] [review] Apply to gnucash-docs 2.4
Created attachment 233565 [details] [review] Apply to gnucash trunk
Created attachment 233566 [details] [review] Apply to gnucash 2.4
Review of attachment 233563 [details] [review]: Accidentally deleted an important note about entire transaction being shown in search results. Will redo the patch.
Review of attachment 233564 [details] [review]: Accidentally deleted an important note about entire transaction being shown in search results. Will redo the patch.
Created attachment 233644 [details] [review] Apply to gnucash-docs trunk
Created attachment 233645 [details] [review] Apply to gnucash-docs 2.4
Hey Geert: can you commit the new tip to gnucash (trunk & 2.4). Thanks
I certainly can commit it to trunk (done in r22711). But I seem to remember that no new strings should be added to the stable branch. I have asked on the devel list to confirm this to be sure.
(In reply to comment #19) > I certainly can commit it to trunk (done in r22711). But I seem to remember > that no new strings should be added to the stable branch. I have asked on the > devel list to confirm this to be sure. Thanks Geert!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=604519. Please update any external references or bookmarks.