Bug 739571 - Matching imported transactions doesn't indicate previously matched entries

[Jesse Olmer]

On Sat, Jan 23, 2016 at 7:26 PM, John Ralls <jralls at ceridwen.us> wrote:
>
>> On Jan 23, 2016, at 5:18 PM, Jesse Olmer <jesse at wickedgoodtimes.com> wrote:
>>
>>> Why not just add a gboolean "used" attribute to _matchinfo, set it true when the corresponding transaction is used in a match and exclude the instance from the match_list if its used attribute is true?
>>
>> I think there's two problems with that. _matchinfo instances are not
>> shared across multiple transactions, they're created in
>> split_find_match during the transaction initialization, so we can't
>> use it to track whether any other instances have it as a pending
>> match. The second problem is that whatever common data location is
>> used needs to be able to ref count because multiple transactions could
>> have the same best match based on the heuristic. A simple bool causes
>> a problem when the user goes into the match picker for one of these
>> transactions and changes it to a different item - we can't just set to
>> false because it could still be a match for another transaction.
>>
>> Additionally, I think it's probably going to be useful to be able to
>> indicate to the user whether the pending match is an automatic or
>> manual selection, so having that reference back to the
>> _transactioninfo(s) or pulling that data along in a new object would
>> be necessary.
>
> Ah, I see that match_info is private to transactioninfo, so the list of already-matched existing transaction has to be maintained outside of matchinfo, and the transactioninfos are all loaded at once at the beginning, so that's the wrong list.
> The right one is the GtkListStore *store in import-match-picker.c. How about keeping a GHashTable of GUIDs of transactions or splits, which ever is easier, that have already been matched and filter out adding any transactions whose GUIDs are in the GHashTable? There's already a guid_hashtable_new() for you in src/libqof/qof/guid.h.
>

Yeah that's essentially what I'm doing so far (although it'll need a
bit of a rewrite if C++ isn't cool in maint). Instead of a hash table
I'm using an unordered_map<GUID,
TypeWhichDoesRefCountAndMatchTypeIndicator> which lives in
_main_matcher_info and gets passed in to each match picker instance
via gnc_import_match_picker_run_and_close. Filtering & display happens
where you'd expect in match_update_match_model, and refcount updates
are handled in the result of gnc_import_match_picker_run_and_close.
Having to switch to C will take me about a day but hopefully I'll have
something ready tomorrow.

On Sat, Jan 23, 2016 at 4:56 PM, Tracy <tracy at arisiasoft.com> wrote:
>
> Or display an indicator showing that it has been previously matched (in case
> someone wants or needs to match two imported transactions to the same
> existing register transaction)....

No worries Tracy, that part's already done
(http://i.imgur.com/XYVX5hp.png). It's just handling the pending
matches in the current import that's the more difficult part.