I can't find where this bug was originally described but I verified it: If you import an OFX file, transactions that are marked for anything else than Matched are not highlighted when you move the cursor. This means you can't see which transaction you're looking at. In the code this seems to be intentional. There's a function that prevent transactions marked for ADD, or UPDATE to be selected. I do not know why this is the case, and there's no comments in the code. A consequence is that you can move the cursor up with the arrow keys, but you don't see which transactions the cursor is on, unless it's marked for a match (not add, not update). Anybody knows why that would be the case? Jean
It is likely buggy code. If you can produce .gnucash, .ofx, and .patch, when we can all verify that your fix is better code.
It was done intentionally. Here's the commit message: (caeea74b5003788a79fd684e50244dac44f11e93 ) Author: David Cousens <[hidden email]> Commit: David Cousens <[hidden email]> Add view_selection_function view_selection_function added to only allow adding a row to the selection if GNCImport_Add is set for the transaction. Explicit selection clearing try explicitly clearing the row in the add, update and clear toggle callbacks - before refresh row and add debugging info which showed that the selection is called after exiting the above callbacks and as the view_selection_function has no knowledge that the add checkbox has just been toggled it allows the row to be selected. Requires a flag to be set in the add_toggle_cb which prevents selection in the view_selection_function and is cleared there. Fix row being selected after A(dd)toggled When the A is toggled on from U+R or R the row is automatically selected and if the row is toggled back to U+R or R selected, it cannot be unselected. Add a global add-toggled flag set in the gnc_gen_trans_add-toggled_cb and used in the treeview multiple selection function to prevent a row being selected immediately after the A has been toggled. Fix to Multiple selection to ensure the match dialog comes up on double click on a reconciled or update row and implement a view_selection_function so that only rows flagged for addition can be added to a selection Fixes requested by Bob-IT removed global add_toggled variable and added it to _main_matcher_info structure. modified gnc_gen_trans_add_toggled_cb and view_selection_function to use the _main_matcher_info member.
I think Bob Fewell (Bob-IT) reads bugmail regularly. I'm not so sure about David Cousens. Perhaps an email to gnucash-dev with a link to this bug would prompt them to explain more fully.
I previously raised this as Bug 796154, which I will now close as this has progressed further. Of interest from Bug 796154: 1. Highlight disappears after assigning transfer account 2. Jean Laroche was doing some work on the match dialog under PR 710 https://github.com/Gnucash/gnucash/pull/710 which may impact this bug. PR 710 is now closed, and I think it has been replaced by PR 697 https://github.com/Gnucash/gnucash/pull/697
*** Bug 796154 has been marked as a duplicate of this bug. ***
The highlight disappearing after account selection could probably be fixed by adding a gtk_tree_selection_select_path after said account selection not sure when multiple transactions selected. If you did not see the comment on the list I think the function view_selection_function is to do with rubber banding for selection. It may help with a screen shot, I can get rows to highlight OK when they are green/gold with A ticked.
OK, what I was missing was what you can do once you multi-select several transactions, I didn't realize you have the option to assign the transfer account. So this is useful, and the behavior is by design. The fact that the highlight disappears once you've selected the account, does that really matter? Since you're done assigning the transfer account and there's no additional operation possible, it does not seem like a severe bug to me. In my humble opinion, I find it confusing that the multi-selection disallows some of the transactions. What if we allowed rubber-banding transactions that can't currently be selected but did nothing about them when assigning the transfer account? Would that also be confusing? More confusing ? Less confusing? Jean
Hi Ripngo (What's your real name? RipnGo doesn't really inspire confidence, but thanks for looking at this), The fact that the highlight disappears once you've selected the account is not a severe bug, but it does make it much more difficult than it needs to be, working your way thru the transactions, especially in a big list of transactions. I hadn't thought of rubber banding, and I can't see how that would be really useful. It would be unlikely that multiple sequential transactions would need to be assigned to the same tfr account. It would be confusing if some transactions were selected but not actioned, so I suggest: 1) If the idea of not being able to select trans that cannot be assigned is to continue, then the program should, after a multiple selection, run thru the selected trans and unselect those not able to be assigned. Then, after assignment, I suggest the first transaction able to be selected after the first transaction in the selection, should be highlighted as (in my case anyway) the user probably found a transaction that needed to be assigned a tfr account, then control-clicked the others after it in the list that also needed the same tfr account. 2) I would really prefer that it should be possible to select any transaction, and the assignment function did nothing to those it should not assign, but I can see that's still a little confusing. If anyone else has suggestions, please speak up.
I would not think it much trouble to select all transactions after assignment. My choice would probably leave the selection as is, generally if you can not do any thing with it, do not allow it to be selected just like OK buttons should not be actionable until all required activities are completed. Either way you will get people asking why the selection was changed / not selected. Bearing in mind I do not use this.
Created attachment 373699 [details] Patch to reselect rows Jean, Just some lines to reselect all previously selected rows. If you want I can push this to master or you can add to whatever you have in mind.
Go ahead Bob, I don't have anything in mind for this bug. I'm just not sure how to best fix that, as it looks like we need to disallow selections for some transactions, and that conflicts with showing which transaction is currently under the cursor. I'm not sure whether that's possible code-wise, but perhaps we can allow highlighting the transaction under the cursor when only 1 transaction is selected, for example when you move the cursor with the arrows, but when a multi-selection is done, un-actionable transactions are deselected? Perhaps that's the best of both worlds? Jean
(In reply to Chris Good from comment #8) > Hi Ripngo (What's your real name? RipnGo doesn't really inspire confidence, > but thanks for looking at this), He's Jean Laroche.
(In reply to Chris Good from comment #8) > I hadn't thought of rubber banding, and I can't see how that would be really > useful. It would be unlikely that multiple sequential transactions would > need to be assigned to the same tfr account. On the contrary, it's quite common for services like iTunes to charge each download individually. Buy 5 tunes in 20 minutes and you get 5 identical lines in a group.
OK, Have pushed my changes to reselect the transactions after account assignment to master so will be in version 4.0
Bob, I submitted a PR https://github.com/Gnucash/gnucash/pull/724 as an attempt to both get highlighting of the transaction under the cursor, and the removal of transactions based on their flag, for rubber banding transactions.
