Transaction Report not showing all tagged transactions

[GFSMT]

MMEX version:

• [ ] 1.6.4
• [x] 1.7.0
• [ ] 1.7.1
• [ ] 1.7.2
• [ ] Other (please specify)

Note: bug reporters are expected to have verified the bug still exists either in the last stable version of MMEX or on updated development code (master branch).

Operating System:

• [x] Windows
• [ ] Mac OSX
• [ ] Linux

Description of the bug

Transaction Report does not present all transactions with requested tag. Presents only splits tagged with requested tag, not "simple" transactions.

Reproduction

Is the bug reproducible?

• [x] Always
• [ ] Randomly
• [ ] Happened only once

Reproduction steps:

1. Create one transaction and tag it.
2. Create another transaction, split categories, tag the splits, not the main transaction, with same tag as before.
3. Open the Transaction Report and set the filter for the tag you used.

Expected result: Both transactions show on report.

Actual result: Only the second transaction (with the splits) will show on the report.

Additional information

NA

[rmelillo76]

I'm unable to reproduce. Is it possible you have other criteria that is preventing the transactions without splits from appearing on the report? Can you share screenshots of the transactions, transaction filter dialog and the report?

[whalley]

I cannot reproduce either, seems to work OK.

[GFSMT]

On one hand I messed the description, on the other there seem to be more requirements I did not notice at first.

First, my mistake: step 2 should be "Create another transaction, split categories, tag the main transaction, not the splits."

Upon reading your messages I tried to reproduce on different PC and the intended result was achived. Then I remembered a detail: the notes field was originally filled. After writing text on the notes field of the splits, the error occured again.

After the error's occurence and after deleting the notes from the split, error repeats.

Creating new transactions, even with no notes from the start, repeat the error.

Created "testing" cash account and transactions, for images: "control" transaction, main tagged, no splits 1st test sample, main tagged, with untagged splits, no notes 2nd test sample: main tagged, with splits, with notes report

[whalley]

First, my mistake: step 2 should be "Create another transaction, split categories, tag the main transaction, not the splits."

OK, I understand what you are saying, and agree that there is an anomaly here. The lookup for tags only matches the splits for a split transaction and not the transaction itself. I guess in this instance if the tag matches the main transaction both splits should be reported irrespective of what tags (if any) they have.

[whalley]

@n-stein Not sure if you defined the record matching to work the way it is? But I think better matching would be done by passing true to mmIsTagMatches(refType, split.SPLITTRANSID, true).

template <class MODEL, class DATA> bool mmFilterTransactionsDialog::mmIsSplitRecordMatches(const DATA& split)
{
    wxString refType;

    if (typeid(split).hash_code() == typeid(Model_Splittransaction::Data).hash_code())
    {
        refType = Model_Attachment::reftype_desc(Model_Attachment::TRANSACTIONSPLIT);
    }
    else if (typeid(split).hash_code() == typeid(Model_Budgetsplittransaction::Data).hash_code())
    {
        refType = Model_Attachment::reftype_desc(Model_Attachment::BILLSDEPOSITSPLIT);
    }

    if (mmIsTagsChecked() && !mmIsTagMatches(refType, split.SPLITTRANSID, true))
        return false;

    return true;
}

Views?

[whalley]

Though that might not actually work!

[n-stein]

I think better matching would be done by passing true to mmIsTagMatches(refType, split.SPLITTRANSID, true).

Though that might not actually work!

indeed, I think adding true here does the opposite of what you are intending: it adds split tags to the main transaction check rather than adding main transaction tags to the split check. The latter is always done via these lines:

https://github.com/moneymanagerex/moneymanagerex/blob/master/src%2Ffiltertransdialog.cpp#L1364-L1369

https://github.com/moneymanagerex/moneymanagerex/blob/master/src%2Ffiltertransdialog.cpp#L1398

After writing text on the notes field of the splits, the error occured again. After the error's occurence and after deleting the notes from the split, error repeats. Creating new transactions, even with no notes from the start, repeat the error.

This part is surprising. The addition of notes should not cause any change in the behavior of the tag check, so this definitely needs a deeper dive to diagnose.

[whalley]

Hmm, did not spot the comment about notes, just the 'step 2 correction' exhibited the behaviour.

@GFSMT Can you please clarify the issue when changing NOTES and the effect on the TAG lookup? Also, you uploaded images do not seem to be displaying.

[GFSMT]

About the notes: On my first attempt at recreating the issue on a different computer (I am running a portable setup), the report worked as expected. Then I added notes to the splits and the report failed to give the correct result and, no matter the changes I made after, the result remained incorrect. As I do not recall the exact steps I took, this part might be better off ignored, for now, as I might have changed something else at the same time as the notes and not remember.

About the images: They were step-by-steps of what I set up to demonstrate the issue and I just pasted them inline on the e-mail reply. Not sure how to make them visible. I can try to add them later, since I can't log in right now.

[n-stein]

About the images: They were step-by-steps of what I set up to demonstrate the issue and I just pasted them inline on the e-mail reply. Not sure how to make them visible

Replying by email strips attached images, you have to add them directly on GitHub.

[GFSMT]

Thanks (new here)! Images updated!

[n-stein]

This is an odd one. The transactions initially show up in the results, but if you click a transaction then press 'OK' to close it, it is then filtered out of the transaction report.

[n-stein]

It seems the Model_Splittransaction cache contains invalid records. When the 'OK' button is pressed on the transdialog, it destroys and recreates the splits in SPLITTRANSACTIONS_V1. For some reason the cache index_by_id_ is not being updated when this occurs, so the call to Model_Splittransaction::instance().get(refId) is returning an invalid record. Bypassing the cache using get_record instead of get works, but obviously it is better to fetch from cache.

[n-stein]

Ok, so the filtering issue was not due to the addition of notes, it was because every time you click "OK" in the transaction dialog the split records are deleted and recreated in the database. It seems saving the split Data_Set all at once was causing the cache data to fall out of scope at the end of the update method. This left the split id still in cache but pointing to a bogus memory block, so subsequent calls to get failed to return valid records until the program was reset and the cache was rebuilt. Saving the records one by one seems to work as expected, so I have adjusted the code accordingly.

This should resolve the filtering issues you were experiencing. Please test the beta and let me know if it is working as expected.

[GFSMT]

Seems to be working properly!

[whalley]

It seems saving the split Data_Set all at once was causing the cache data to fall out of scope at the end of the update method. This left the split id still in cache but pointing to a bogus memory block, so subsequent calls to get failed to return valid records until the program was reset and the cache was rebuilt. Saving the records one by one seems to work as expected, so I have adjusted the code accordingly.

Good work, those are always tricky bugs.