https://bugs.kde.org/show_bug.cgi?id=319807
Jack <ostrof...@users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ostroffjh@users.sourceforge | |.net --- Comment #5 from Jack <ostrof...@users.sourceforge.net> --- I have to agree it's not a bug, but perhaps the feature doesn't really serve it's purpose as originally designed. Note that when you select what you call a memorized transaction - it's not "memorized" in any special way, it's just one previous transaction for that payee. The new transaction is then created as a complete copy of that old transaction. A transaction has a number of splits, and there isn't a "primary" split, although it is sometimes easy to think of it that way. I suspect the memo of the transaction itself as well as the memo of each split (they can actually all be different) are copied. (I have not tested this right now, but I'd be surprised if this isn't what happens.) When you do create a new transaction by copying an old one this way, I think it should be your responsibility to check the splits before accepting the transaction. If you need to make changes, then perhaps it would have been better to not copy but just create a new transaction from scratch. If you want to be able to copy an old transaction with certain parts of it (amounts or memos, for example) blanked out, that would be a reasonable enhancement request. Just because it doesn't do what you want or expect doesn't necessarily make it a bug. There is a bit of perspective involved. However, if the manual describes this in an incorrect or misleading way, please let me know, and I'll look at rewording the documentation. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel