https://bugs.kde.org/show_bug.cgi?id=374352
--- Comment #15 from NSLW <lukasz.wojnilow...@gmail.com> --- (In reply to Thomas Baumgart from comment #14) > I might have to revert this last change by Lukasz because it changes the > behavior of the matching process and may break existing installations (mine > as well ;) ). I have not found all the details, but there was a reason for > this change back in Dec. 2008 (wow, we come a long way) > > http://kmymoney2.cvs.sourceforge.net/viewvc/kmymoney2/kmymoney2/kmymoney2/ > converter/mymoneystatementreader.cpp?r1=1.62&r2=1.63& > > on line 813. The checkin comment says > > Reworked matching logic so that in case of multiple payees match, > the one with the largest match is taken. This returns the name > matching to the 'old' functionality of partial matching. > > and thus we wanted the 'partial matching' which Lukasz removed with his > change. > > A better solution to fix the problem here would be to setup the matching of > newly created entries to be exact which means to simply enclose them in ^ > and $ and assign the MyMoneyPayee::matchKey method instead of > MyMoneyPayee::matchName in MyMoneyStatementReader::processTransactionEntry() > where the MyMoneyFile::addPayee parameters are constructed. This should > solve the issue as well w/o interfering existing databases. > > I therefore reopen the tracker entry. In which way it breaks existing installations? Your suggestion would allow creating of all payees during first import as expected, but, as I assume, if you've already got "Transfer to Checking" and "Check" in your payees list then: "Check" will match with "Check" as expected but it will also match with "Transfer to Checking" as described in this bug. MyMoneyPayee::matchKey and MyMoneyPayee::matchName doesn't matter here, because user can change it freely after first import. What's your opinion? -- You are receiving this mail because: You are watching all bug changes.
