Bug 338272 - Payee deleted in target account upon modifying account of multiple transactions
Summary: Payee deleted in target account upon modifying account of multiple transactions
Status: RESOLVED WORKSFORME
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.6.4
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2014-08-14 16:24 UTC by BobSCA
Modified: 2018-10-29 02:15 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description BobSCA 2014-08-14 16:24:07 UTC
If I select multiple transactions in Account1 which each initially have an unassigned account and change the category/account to Account2 then they appear in the Account2 ledger with no payee. In the Account1 ledger they continue to appear as expected with the correct payee. In my test case, the problem was reproducible only with imported transactions and not with transactions that entered manually.

Problem occurs both when using the transaction form and when editing in the ledger.

Reproducible: Always

Steps to Reproduce:
1.Import multiple transactions into Account1 from OFX file.
2.Select multiple transactions and click Transaction | Edit.
3.Change category/account field from *** UNASSIGNED *** to Account2.
4.Click "Enter" button.
Actual Results:  
The Account2 ledger shows that the payees of these transactions are blank.

Expected Results:  
The Account2 ledger should shows the correct payees of these transactions as shown in the Account1 ledger.

Possibly related to <a href="https://bugs.kde.org/show_bug.cgi?id=332793">bug 332793</a>.
Comment 1 Thomas Baumgart 2014-08-14 19:03:59 UTC
For some reason, I remember that this behavior is by design, but I cannot remember the details that led to it. It is not related to #332793, sorry.
Comment 2 Cristian Oneț 2014-09-23 13:31:01 UTC
I'm not sure this is an issue at all, if I understand correctly the payee is not visible from the account of the second split?

The payee is stored at the split so you could have a transaction with different payees depending on the account from which you are looking at the transaction.
Comment 3 BobSCA 2014-09-24 14:29:49 UTC
The problem does not involve splits (as in a sum composed of multiple sources).

I am simply attempting to assign to more than one transaction a single account (as might occur in a transfer of funds between two accounst). I've recently found that the problem also occurs when assigning to more than one transaction a single category. 

If I select a single transaction in the ledger of Account1 and change the account/category field to Account2, then I get the expected result -- the transaction has the same payee when viewed in Account1 or in Account2.

It makes no sense to me that if I instead select 2 or more transactions and perform the same operation, then the payee information is lost (but only in one of the two ledgers where the transaction is visible). This is an insidious problem as there is no indication that the information was lost. I personally have set the account of hundreds of transactions this way during weeks of use before I realized that the payee field of all these transactions has been erased in one of the ledgers.

I chose to use KMyMoney over GnuCash partially because of the ability to select and operate on multiple transactions. But that feature is less than useful if it results in a loss of data, especially without warning.
Comment 4 Cristian Oneț 2014-09-29 11:22:18 UTC
Is this issue the same with the problem reported by Allan in comment #6 of BUG 332793?

https://bugs.kde.org/show_bug.cgi?id=332793#c6
Comment 5 Ralf Habacker 2017-06-27 14:29:13 UTC
For been able to reproduce this issue it is required to get a simple ofx test file containing the mentioned ofx transaction.
Comment 6 Ralf Habacker 2018-01-17 00:11:34 UTC
(In reply to BobSCA from comment #3)
> The problem does not involve splits (as in a sum composed of multiple
> sources).
> 
> I am simply attempting to assign to more than one transaction a single
> account (as might occur in a transfer of funds between two accounst). I've
> recently found that the problem also occurs when assigning to more than one
> transaction a single category. 

I retested this with 4.8.1 and it works as expected.

(In reply to BobSCA from comment #0)
> If I select multiple transactions in Account1 which each initially have an
> unassigned account and change the category/account to Account2 then they
> appear in the Account2 ledger with no payee. In the Account1 ledger they
> continue to appear as expected with the correct payee. In my test case, the
> problem was reproducible only with imported transactions and not with
> transactions that entered manually.

To check if the issue is also fixed a minimal ofx file containing two or more transactions is required. 
Unfortunally there are several variants to create such an ofx file and it may not trigger the issue, if it is still present.
Comment 7 Thomas Baumgart 2018-01-20 13:13:02 UTC
The problem can still be reproduced in master. Here's howto reproduce it w/o online banking. The scenario is the same.

a) create two transactions to one or two payees but leave the category unsassigned
b) select both of them
c) assign another account as transfer account
d) open the ledger of the other account
-> transactions don't have a payee assigned

The reason for that is, that the payee is kept with the split for the account. When there is no category or account assignment, then the transaction only has that one split. In case you now add a category or account, the second split is created and the second account assigned. In case of a single transaction edit the payee is also copied. In case of a multi-selection edit this is not performed, since for multi-selection edit only those fields are changed that contain data in the widget. Since the payee is empty, it is not modified.

So far things work as they were designed. This does not mean that they cannot be changed if there is a desperate need for that.
Comment 8 Andrew Crouthamel 2018-09-28 03:40:33 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Andrew Crouthamel 2018-10-29 02:15:16 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!