----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108489/#review26534 -----------------------------------------------------------
It's been a while since I posted the review, hopefully you had time to take a look at it. Let me summarize what I discovered when writing the tests and what are my proposals on how to change some behavior. kmymoney/converter/matchfindertest.cpp <http://git.reviewboard.kde.org/r/108489/#comment20169> Current behavior: If there's an existing transaction (ledgerTransaction) with bankId set, refering 'payee', and one imports a transaction with same bankId, refering a different payee - 'otherPayee' - the imported transaction (importTransaction) will be found as a duplicate of existing one. Wanted behavior: I believe this should be corrected, so that the importTransaction could be a duplicate only if both transactions refer the same payee, or at least one of them does not refer to any payee. This is how "regular" matching works right now. kmymoney/converter/matchfindertest.cpp <http://git.reviewboard.kde.org/r/108489/#comment20170> Current behavior: If there's an existing transaction (ledgerTransaction) with bankId set, marked as matched (isMatched() method returns true), the importTransaction will be a found as a duplicate of existing one. Wanted behavior: Imported transaction should be considered a duplicate only if existing one is not matched already. This would align behavior of 'duplicate matching' and 'regular matching' as well, as shown in test testNoMatch_splitIsMarkedAsMatched(). kmymoney/converter/matchfindertest.cpp <http://git.reviewboard.kde.org/r/108489/#comment20171> Current behavior: According to testPreciseMatch_importBankId() (not the code snippet above!): importing a transaction with bankId set can give a "regular" match with existing one, even if it does not have a bankId set. And according to testNoMatch_ledgerBankIdNotEmpty() - importing a transaction with no bankId set will never give a match with existing transaction if it has bankId set. So there's asymmetry, is it justified? Wanted behavior: Imported and existing transactions can be matched ("regular" match, not a duplicate!) if none of them, or one of them has bankId assigned, but it should not matter which one it is. Looking forward to hear your opinions! - Łukasz Maszczyński On Jan. 19, 2013, 5:08 p.m., Łukasz Maszczyński wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108489/ > ----------------------------------------------------------- > > (Updated Jan. 19, 2013, 5:08 p.m.) > > > Review request for KMymoney. > > > Description > ------- > > Added some tests to characterize application behavior regarding matching an > imported transaction with existing/scheduled one. > > I'd like to emphasize two important things in this review: > 1. I've marked three tests with a comment "revise behavior", I believe they > show unwanted behavior. Description of what I think should be expected is > inside the test functions, so please comment those parts and let me know if > my understanding is (in)correct. > 2. I've removed a check, which I believe is superfluous - > splitsReferenceSameAccount(), as transaction filter already takes care of > filtering off the transactions which refer to a different account. I believe > the 4 tests (*_accountMismatch_* and *_multipleAccounts_*) show that this > check is not needed, however it was in the code for a long time, only > rewritten during recent refactoring. > > > Diffs > ----- > > kmymoney/converter/CMakeLists.txt 8433630af638df863dad55e10a3ead60f0b4c7f6 > kmymoney/converter/matchfindertest.h PRE-CREATION > kmymoney/converter/matchfindertest.cpp PRE-CREATION > kmymoney/converter/transactionmatchfinder.h > 5f276a846de4cc72bd2700f2560a64b8ee260217 > kmymoney/converter/transactionmatchfinder.cpp > 35e72cbc65dde762ed2e11651185afe2c4a14a3c > > Diff: http://git.reviewboard.kde.org/r/108489/diff/ > > > Testing > ------- > > make test > > > Thanks, > > Łukasz Maszczyński > >
_______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
