On Feb 8, 2009, at 10:13 PM, Simon Ruggier wrote: > On Sun, Feb 8, 2009 at 7:40 PM, David Reiser > <dbrei...@earthlink.net> wrote: >> >> On Feb 8, 2009, at 6:07 PM, Simon Ruggier wrote: >> >>> On Sun, Feb 8, 2009 at 3:51 PM, David Reiser >>> <dbrei...@earthlink.net> >>> wrote: >>>> >>>> This patch has some nasty side effects. It tries to change assigned >>>> target >>>> accounts on the fly within a single import. If I have several ATM >>>> deposits >>>> in one import, most of them will come up assigned to the last >>>> assignment >>>> from a prior import. When I change the first one to its proper >>>> account, >>>> your >>>> patch results in the rest of the deposits also being assigned to >>>> the >>>> account >>>> just entered. That's not so good, but not the end of the world (and >>>> definitely not what gnucash has done in the past). >>> >>> So basically, before, you'd have to be doing a new import for the >>> automatching to happen, >> >> That isn't what happens on my system, but my data file has been >> accumulating >> for so long, I'm not sure what was already there when the switch to >> the >> GTKTreeModel happened. > > What happens on your system?
Hmm. Looks like I misread or was otherwise confused. The 'normal' action is for the account assignments to happen one-time-only per import when the matcher window is first opened. After that it's all manual for changing the target accounts one at a time. > > > Also, note that I started using GnuCash after the switch happened. I'm > probably going to make a patch for the two things I mentioned before > whenever I get a chance in the next few weeks, I don't think it's > right that the patch I submitted breaks the workflow where the user > moves from top to bottom, setting destination accounts and verifying > the automatches for correctness at the same time. I also won't think > it's right if I make it really easy for the user to game their match > data by toggling the add checkbox repeatedly, so I'd have to implement > both changes. > > One could make the loop only trigger automatches for transactions > after the one that was just set, but that's a bad idea, because it > assumes that the user is moving downwards only, and the user doesn't > know that we're assuming that, so they could get bitten if they jump > back up to the top of the dialog and change something without > rechecking all the automatches below it (of course, with this patch, > they're getting bitten with the loop now no matter what direction they > go in, for now). > >>> Are you sure that the first deposit gets reassigned in the case >>> where >>> it is a manual deposit? The matching code clearly attempts to avoid >>> matching transactions that were manually set (in import-backend.c at >>> gnc_import_TransInfo_refresh_destacc). >> >> Yes, I'm sure. I watched it happen in an import. > > I'm at a loss to explain that, since the same flag that is used to > choose whether to put (manual) or (auto) next to the text in the > destination column is used in the decision to skip automatching a > given import transaction. As far as I know, the flag is only set to > false (i.e. auto) when the transaction is first added to the list, and > the loop in automatch_store_transactions doesn't change any > transactions where the flag is true. If the list shows "transfer to > (manual)" next to the destination account name, the automatching stuff > shouldn't be changing that transaction. > > However, if you have a transaction that the match data isn't really > familiar with, and you select an account for it manually in the import > dialog, then hit cancel, and then reimport the same file, the import > code will (most likely) match the same transaction to the destination > account, but it will show (auto) instead of (manual). Could that be > what happened? My recollection is that I never cancelled the import. I did change the same target account more than once in some of my attempts before OKing the import. Then I closed the data file without saving and reattempted the import from the same checkpoint using the same ofx data file. -- David Reiser dbrei...@earthlink.net _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
