GNOME Bugzilla – Bug 684709
Clarification of the find transaction assitant
Last modified: 2018-06-29 23:10:52 UTC
Created attachment 225056 [details] Suggested modification to sction 7.1 of the help manual Changes suggested by David: "I am attaching a marked up document suggesting changes to section 7.1 of the help manual to give clarification to how the Find Transactions assistant works. Please consider revising the document as noted. Thank you David"
It would be helpful if the changes were highlighted in some way, so reviewers can quickly examine those changes. I don't see them in the attachment. This makes evaluation a line-by-line affair, which is time consuming. To begin: You add: "When selecting your search criteria keep in mind the fact that the criteria are applied to individual 'sides', lines or fields in transactions, but the entire transaction is included in the results register display. There is no visual indication of which lines or fields actually meet the search criteria versus which lines come along for the ride." Stylistically, I'd recommend: "When selecting search criteria keep in mind that criteria are applied to individual splits or fields in transactions, and that the entire transaction is included in the results. There is no visual indication in the results to indicate which split or field met the search criteria." David
When I use Open Office 3.4.0 to view the file that I submitted, my additions and deletions are printed in a different color (brown, I think) than the base text (definitely black) that I started from. I am not sure why you do not see that with your text editor. As to your recommendation regarding wording in paragraph 2, I am not married to my wording as long the concepts are presented clearly. I think that you are clearly presenting the concept. Paragraph 3 updates the instructions to match the new way that the assistant is used in release 2.4.11. Paragraph 7 is intended to explain the differences seen when starting a search from different reference points. In the table I identify which fields are common vs which are tied to a particular split line. After the table I add a note to point out that the Reconcile field may differ among the split lines. I am not sure whether the statuses of New and Cleared can be searched for. Lastly I have created a table to list the various values that the reconcile field may contain. I think that table may best fit in the Tutorial and Concepts Guide. David C
Aha. Perhaps you need to select Edit:Changes:Show in Open Office. David C
... assuming, of course, that one is using Open Office in the first place. I would prefer some sort of text-based editorial markup--something that is visible in Bugzilla directly. Others may not feel that this is appropriate, however. David T.
Created attachment 225157 [details] [review] Reconcile column description table I attach two patches: - One is for the help and updates the find transaction assistant. - One is for the guide and adds a table with description of the reconciliation status (R column in the register) Both patches needs more work as I'm not sure if the Reconciliation status table fits better in the guide or in the help. I also need to proof-read (and test directly) the first patch about the find transaction assistant.
Created attachment 225158 [details] [review] Find transaction assistant
I know non plain text files are not good as bug attachments but I needed a draft of what the bug was about and David Carlson provided the odt format. As I understood, he's not able to create a patch and I didn't want to loose his help.
Created attachment 225161 [details] Proposal in plain text format Thank you Cristian Marchi for creating those patch attachments. While you were doing that I was busy trying to reduce my request to plain text. I will include it here in case it helps to work on those patch attachments. David C
I just remembered that Table 7.1 is not clear in the section about the reconcile button choices whether more than one choice can be selected in a single search element. In fact, I think that it should be limited to one choice per search element, but it is possible to actually select more than one choice and I think that produces ambiguous results. I believe this issue also arises in the other applications of the search assistant mentioned at the beginning of section 7.1 I do not have a specific suggestion to resolve this point. I also forgot to include a paragraph that I proposed to explain the search refinements possible by starting in a single account register and by right clicking and using the filter by choice. To that end I propose to add just before Table 7.1 the following paragraph: "To search within a smaller group of transactions, you may start from within a single account register and also use the register view 'filter by..' option to include a limited number of transactions. When starting from a single account register, only the parts of transactions applying to that account are searched. Thus the transfer accounts, notes and transfer values are not searched, but they do appear in the search result register." David C
There is also no description about how the type of search choices tat are available in the Find Transactions search window work. While they are fairly self explanatory, I think that the existence of the choices bears mentioning. Thus I propose that the choices be enumerated as follows: "It is possible choose one of these options when defining a search: 1. New Search 2. Refine current search. 3. Add results to current search 4. Delete results from current search" Last, if someone knows what the box labelled "Search only active data" means, that should be explained. David C
Just to use it as a personal reminder, also the first paragraph of the Find transaction assistant section needs work: "Find Transactions is used to search for transactions in GnuCash and display the results in a register window. The Titlebar of the Find Transactions dialog contains Search For... and the first line of the dialog has Split Search. In other search dialogs used in GnuCash the first line contains a different description but the same basic layout" The titlebar is "Find Transaction" and not "search for", the first line change if you open the dialog from a register (split search) or with business-XXXX-find XXXX (you get XXXX search)
I've just commited a patch to trunk for this bug [1]. I've rearranged the text, divided the section in two part (Split search and business search), added and updated the tables with the possible combination of search criteria. The changes will be visible online tomorrow when the server builds the documentation [2] I leave the bug open for comments and errors reporting. [1] http://svn.gnucash.org/trac/changeset/22438/ [2] http://code.gnucash.org/docs/help/tool-find.html
That is a very detailed expansion. Nicely done. However, I am confused by the word both as you use it in footnotes d and e of table 7.1. Does that actually mean every line (multiple line splits have more than two lines)? Is it valid to to select any number of accounts for these criteria? Does matches no accounts actually mean "is not one of the selected accounts" Will users know how to select more than one account from the list without a suggestion to use the ctrl key or a reference on how to navigate the account list (if there is one)? I think there should be a caution in Table 7.1 footnote c to only select one reconciliation criteria per search criteria row. The note that companion lines of found transactions may differ is very important to keep. The note does not tell where to look for the definition of reconcile status values. I am guessing that will become a link when it is known. The new tables 7.2 through 7.8 have items flagged with footnote b but the footnote is not repeated after the respective tables. A very minor point, but it does detract from the otherwise very nicely done work.
(In reply to comment #13) > That is a very detailed expansion. Nicely done. However, I am confused by the > word both as you use it in footnotes d and e of table 7.1. Does that actually > mean every line (multiple line splits have more than two lines)? Is it valid > to to select any number of accounts for these criteria? Does matches no > accounts actually mean "is not one of the selected accounts" Will users know > how to select more than one account from the list without a suggestion to use > the ctrl key or a reference on how to navigate the account list (if there is > one)? Footnotes d and e comes from the previous version of the documentation. I haven't tested what they describe. Will try to do it... > > I think there should be a caution in Table 7.1 footnote c to only select one > reconciliation criteria per search criteria row. The note that companion lines > of found transactions may differ is very important to keep. The note does not > tell where to look for the definition of reconcile status values. I am guessing > that will become a link when it is known. I'm moving the reconcile section described in the account section to the assistant section. Then I will put the link to the reconcile status values table. > > The new tables 7.2 through 7.8 have items flagged with footnote b but the > footnote is not repeated after the respective tables. A very minor point, but > it does detract from the otherwise very nicely done work. I know, it's a limit of the html template. The alternative is to use a different letter for every table although the word referring to the note is always the same. If have the chance to look at the pdf or to the integrated help in your distribution you will see a different behaviour for each.
Hi People, What's happening with this? It would be a shame if all this good work was lost.
I think that this bug report can be closed because the result is now in the help manual, although it is now chapter 8 as the result of other work.
(In reply to David Carlson from comment #16) > I think that this bug report can be closed because the result is now in the > help manual, although it is now chapter 8 as the result of other work. OK
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=684709. Please update any external references or bookmarks.