Version: Version 3.96.1-svn1095919 (using KDE 4.3.5) OS: Linux Installed from: openSUSE RPMs If the details column contains 5 lines, probably from having been matched, the two lowest lines are clipped - the top of the fourth line is missing, and the bottom of the fifth line. It appears as though only four lines are expected. If the details column contains 7 lines, the bottom two lines only are clipped. It appears as though only six lines are expected. Downloads were via OFX, and matched against scheduled items containing a single word memo.
Just realised that this is apparent only before the entry is accepted.
Could you try this with the new ledger, just to get an updated description of this. I have here 6 lines in the details column and everything is OK. I don't know how you could get 7 lines since AFAICT from the code there could only be 6 lines for a matched transaction that is selected (while using the ledger lens also).
Now on Version 3.97.2-svn1121075. At first, I thought it was fixed and couldn't find any 7-liners, but in fact there is one, and the description is exactly as before. The description reads as follows - " PAYEE account comments from schedule and payee matching regex (two) KMM has matched...... <right side clipped> date with download payee date with schedule comment <top clipped> download payee match detail <bottom clipped> " I think the regex entries are relevant. Also, when I unmatched the entries to examine each, I was then not able to re-match, as right clicking to get the context menu de-selected that entry.
This has been rendered invalid due to the port of the ledger to full Qt4. There will be other problems, but this specific one is probably not going to be there or it's going in another way.
So, it's not actually fixed at the moment, but will be. Should we not then leave it as outstanding, rather than 'fixed'?
Leave it outstanding as I'll fix it as soon as I can reproduce it. The problem is that I don't have OFX downloaded transactions so saving your file in an anon version and pointing me to the account and the transaction where I can reproduce this would really help fixing this. Thanks.
The anon file does not reproduce the problem, because the format in 'Detail' is different. I'll see if I can produce a file, or change this one.
What I meant is that this bug is reported on the behaviour of KDE 3.x widgets, and all that has now been ported to full KDE4. so that makes the report useless. But so be it, let's leave it open for a while and hope it is of some use.
Can you say in what svn it was fixed, because as in comment #3, I was still seeing it on 3.97.2-svn1121075. That's why I said in Comment #5 From aga 2010-05-03 10:57:46 (-) [reply] ------- "So, it's not actually fixed at the moment, but will be." If it's fixed in a later svn, I'll give that a whizz. I'm trying to get an anon file for Cristian in the meantime.
(In reply to comment #9) > Can you say in what svn it was fixed, because as in comment #3, I was still > seeing it on 3.97.2-svn1121075. > > That's why I said in Comment #5 From aga 2010-05-03 10:57:46 (-) [reply] > ------- > "So, it's not actually fixed at the moment, but will be." > > If it's fixed in a later svn, I'll give that a whizz. I'm trying to get an anon > file for Cristian in the meantime. If it's there in 3.97.2-svn1121075 then it's still there in the current SVN since the ledger was ported in revision 1121021.
Created attachment 43199 [details] the qif file
Well, that took some time, but finally I've got it. Here are three files - test.kmy, test-after.kmy, and test.qif, which I produced from a .csv file, so easier to look at. If you load test.kmy, then import test.qif into account aga, you should see a result as in test-after.kmy. From the problems I had producing the conditions, it would seem that it all hinges on the existing entry in test.kmy, which was produced from a scheduled item matched with a previous download, and having a memo field with two lines. If you delete the second line, the problem doesn't show up.
Created attachment 43200 [details] before file
Created attachment 43201 [details] test file after import
SVN commit 1122367 by conet: BUG: 228781 We only have one line for each detail in the ledger so remove any newline characters when displaying data in the ledger to avoid clipping multi-line text. M +2 -2 stdtransactionmatched.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1122367
This problem has resurfaced, almost certainly because I have multi-line memos. As before, it shows when a download matches an existing item. Accepting the match resolves things. Seven lines appear in Details, the first four and the last are correct, but the top of the fifth and the bottom of the sixth are clipped. In fact, I would say that one line doesn't show at all. However, if I open the transaction, the memo shows everything correctly. Prior to import, the item was a scheduled entry, with a single line memo. The import contained three memo lines. As said above, accepting the match produces the correct details.