Bug 404753

Summary: changing multiple transactions with bulk edit in ledger is not reflected in a report showing those transactions
Product: [Applications] kmymoney Reporter: Jack <ostroffjh>
Component: reportsAssignee: KMyMoney Devel Mailing List <kmymoney-devel>
Status: CONFIRMED ---    
Severity: normal CC: antoine
Priority: NOR    
Version: git (master)   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Test xml storage file

Description Jack 2019-02-23 23:26:59 UTC
(actually git head 5.0 branch, but likely same in master)

(originally reported to the dev mailing list 4/4/2018)

I display a report ("tax transactions by category" is where I noticed) and find an issue in the memo of several transactions.  I then go to the ledger, edit one transaction to fix the memo, and go back to the report, it reflects the change I made.  On the other hand, if I select multiple transactions and edit them, the change is NOT shown when I go back to the report.  Even if I save the file, close KMM and restart, those memo changes are shown in the ledger, but not in the report.  If I edit one transaction, don't change anything, and save it, then the changed memo is shown in the report.

I assume the report results are cached somehow, so is there a way to completely refresh that cache?  Shouldn't the report know that multiple transactions have been changed by a bulk edit?
Comment 1 Thomas Baumgart 2019-02-24 09:52:22 UTC
I try to shed some light on this behavior and maybe explain it. First of all: there is no cache. This is why you don't see any changes when restarting the application.

I expect the following happens (but have not checked in code yet): When editing a single transaction the memo of both splits gets updated. It could well be that this is not the case when editing multiple transactions at once.

Example: if you have a transaction in account A1 which is categorized against C1 then both splits have a memo entry. When you look into the ledger, the memo is extracted from the A1 split. Depending on the report, the one stored with the C1 split can be used. So in case the memo of the C1 split is not updated during multi-transaction-edit then this would explain what you see.
Comment 2 Jack 2019-02-24 16:06:24 UTC
I just did some more testing.  First, when I do a multi-edit, the memo in both splits are changed.  I checked this by looking at both the account ledger and the category ledger.  Then, I changed all the memos to "xxx" and tried again - and the report showed "xxx" for all of them.  It seems that the problem only happens when changing the memo to be empty, but not when changing it to any non empty value, even a single space.

Another thing I just noticed - when I change the memo to empty, and go back to the report, it shows me the same place I was previously looking.  When I change the memos to a non empty value and return to the report, it goes back to the top of the report.  So - it seems that if a multi edit changes the memos to empty, the report doesn't know they have been changed.  Perhaps any edit of a single transaction is detected by the report as a change, so it updates.
Comment 3 Jack 2019-02-24 18:33:32 UTC
More testing, and admit part of Comment 2 is wrong.  Thomas is correct - the memo is NOT getting updated in the other split.  I was looking at the Payee ledger, which seems to show the account side split, and thus shows the new value, even if empty.  If I really go to the category ledger, the ledger entry for the transaction does not show a memo value, but the transaction form at the bottom DOES show the old memo value.  (I now see many transactions in that category ledger where the transaction form at the bottom shows values that do not appear in the main ledger above.)

So, it now appears to me that when doing a multi-edit, removing the memo does not apply to the other splits, but changing the memo to any non missing value does get applied.

This is easy enough to demonstrate with a new file, one account, one payee, one category, and two transactions.  If it would help, I'll be glad to attache such a test file.
Comment 4 Thomas Baumgart 2019-02-24 19:18:51 UTC
That would be cool.
Comment 5 Jack 2019-02-24 20:20:33 UTC
Created attachment 118344 [details]
Test xml storage file

The original memos were "bad category memo" then changed to "bad new memo" then to "".
Comment 6 antoine 2020-07-14 07:57:29 UTC
I confirm this bug
KMyMoney-5.1.0-74a8f0d-x86_64.AppImage
Xubuntu 20.04