With the faeture to multiselect and apply a transfer account to all selected accounts if the selection contains a line which is flagged to be skipped or cleared (or updated ?) GnuCash exits with an error. A user would not normally be trying to assign a transfer account to transactions which are matched to an existing transaction in an account but it is posssible. Proposed fix is to check the trans-info of items in the selection in gnc_gen_trans_onButtonPressed_cb and gnc_gen_trans_onPopupMenu_cb to check that only items flagged for import are selected. Possible actions: 1. Unselect inappropriate items issue a popup warning "Selection contained items to which a transfer account cannot be assigned. These have been removed from the selection" and proceed to process the appropriate members of the selection. 2. Don't display the "Assign Transfer account" popup at all and abort issuing the popup message that the popup contains items to which a transfer account cannot be applied and that their import status should be changed before attempting to add them to a multiple selection and that they should be deselected before attempting to process the selection again. I favour the second approach. AFAIK there is no way to make the selection implicitly selective on the transaction import status at the point of selection. The first approach doesn't force the user to be mindful of the staus of transactions they select, whereas the second informs them and forces them not to include. I will check the treeview to see if there is a flag available to set whether rows can be flagged as non selectable or not but this approach would require changes in other parts of the code where transactions are loaded to implement.
3. Or request popup "Selection contains items already assigned to a transfer account, or already matched. Please choose the following: [Cancel] [Skip matched transactions] [Overwrite matched transactions]" default to Cancel...
Christopher, The most recent mods to this in 3.6 only allow selection of a transaction if the A box is checked and not if either the U+R or R boxes are checked. Currently it doesnt check if a transfer account has already been assigned. I think if I modify the help ot reflect these changes making it clear that if you select a row which has a green background it will over write the transfer file selection. I have had use cases myself where GnuCash has assigned a transfer account on the Bayesian matching but I wanted it to be transfer to another account with a group of other transaction I am assigning a transfer account to. I could probably detect that a line with a transfer account has been included in a selection and popup a warning "You have selected a transaction which already has a transfer account selected" at the time it is selected possibly by just checking the "color" assigned in the matcher_info structure. Having to clear the popup all the time would be a major interruption to workflow however. There is no way however, that I can see currently, to unallocate a transfer account to return a row to a yellow background with no assigned transfer account. This would become necessary if I only allowed rows with a yellow background to be selected (no transfer account assigned) and not any with a green background (transfer account assigned). One would then be restricted to only being able to use the multiple selection with rows with unassigned transfer accounts and to reassign those which did have an assigned transfer account only one at a time. I feel it is fairly obvious that if you include a transaction row which already has an assigned account (green background) to a selection you are obviously going to reassign it. If that's not what you want, don't include green rows in the selection only yellow. The other place would be to modify the popup help dialog to warn that selecting rows with a transfer account already assigned will cause them to be overwritten in the instructions I included there. This has been modified to give instructions for using the multiple selection but the commit didn't make it into 3.6 but will for 3.7. David
David, your Bug 797275 branch was merged some time ago. Should this be closed or is there more work to be done?
