[kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney
https://bugs.kde.org/show_bug.cgi?id=376010 --- Comment #3 from allan --- Frank It is with regret that I need to advise you with the sad news that Allan has passed away. He died on the 14 February at home. I see a number of emails associated with computer based problems, would you be kind enough to pass on the sad news to anyone who knew Allan. Kind regards Barbara (sister in law) Sent from my Samsung device Original message From: Frank Osborne Date: 06/02/2017 17:15 (GMT+00:00) To: kmymoney-devel@kde.org Subject: [kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney https://bugs.kde.org/show_bug.cgi?id=376010 --- Comment #2 from Frank Osborne --- Allan, I couldn't duplicate this first try but I'll work on it this week. It may take me a week or so to get it. You can close this ticket if you want and I'll let you know when/if I can reproduce it. I've used Quicken. MS Money, Moneydance, and others and KMyMoney is the best. You guys did an excellent job. Thanks for the quick response. Frank On Sat, Feb 4, 2017 at 4:08 PM allan wrote: > https://bugs.kde.org/show_bug.cgi?id=376010 > > --- Comment #1 from allan --- > This works for me, although on the development branch. > > Are you able to provide a similar file that shows the problem, together > with > details of the columns you were selecting, please. Is it always the same > column that triggers the crash? > > I don't recollect anything similar. Paypay files were a problem a long > time > back, but that was with the number of columns. > > KMyMoney v 4.14.22 is not a valid KMyMoney revision. You'll find it in the > help menu. > > Allan > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are the assignee for the bug.
Re: [kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney
Frank It is with regret that I need to advise you with the sad news that Allan has passed away. He died on the 14 February at home. I see a number of emails associated with computer based problems, would you be kind enough to pass on the sad news to anyone who knew Allan. Kind regards Barbara (sister in law) Sent from my Samsung device Original message From: Frank Osborne Date: 06/02/2017 17:15 (GMT+00:00) To: kmymoney-devel@kde.org Subject: [kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney https://bugs.kde.org/show_bug.cgi?id=376010 --- Comment #2 from Frank Osborne --- Allan, I couldn't duplicate this first try but I'll work on it this week. It may take me a week or so to get it. You can close this ticket if you want and I'll let you know when/if I can reproduce it. I've used Quicken. MS Money, Moneydance, and others and KMyMoney is the best. You guys did an excellent job. Thanks for the quick response. Frank On Sat, Feb 4, 2017 at 4:08 PM allan wrote: > https://bugs.kde.org/show_bug.cgi?id=376010 > > --- Comment #1 from allan --- > This works for me, although on the development branch. > > Are you able to provide a similar file that shows the problem, together > with > details of the columns you were selecting, please. Is it always the same > column that triggers the crash? > > I don't recollect anything similar. Paypay files were a problem a long > time > back, but that was with the number of columns. > > KMyMoney v 4.14.22 is not a valid KMyMoney revision. You'll find it in the > help menu. > > Allan > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney
https://bugs.kde.org/show_bug.cgi?id=376010 --- Comment #1 from allan --- This works for me, although on the development branch. Are you able to provide a similar file that shows the problem, together with details of the columns you were selecting, please. Is it always the same column that triggers the crash? I don't recollect anything similar. Paypay files were a problem a long time back, but that was with the number of columns. KMyMoney v 4.14.22 is not a valid KMyMoney revision. You'll find it in the help menu. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 129790: Add Capital Gains report
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129790/#review101864 --- Just a query, as I have not studied the code, but are you able to handle the different requirements of different countries? - Allan Anderson On Jan. 7, 2017, 7:50 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/129790/ > --- > > (Updated Jan. 7, 2017, 7:50 p.m.) > > > Review request for KMymoney. > > > Bugs: 250471 > http://bugs.kde.org/show_bug.cgi?id=250471 > > > Repository: kmymoney > > > Description > --- > > This new report presents capital gains calculated using FIFO method and is > displayed in table. > > > Diffs > - > > kmymoney/mymoney/mymoneyreport.h 7397a0f > kmymoney/mymoney/mymoneyreport.cpp 642145a > kmymoney/reports/listtable.cpp 72b605f > kmymoney/reports/querytable.h 7e2bfa1 > kmymoney/reports/querytable.cpp e44f74c > kmymoney/views/kreportsview.cpp c9c9a12 > > Diff: https://git.reviewboard.kde.org/r/129790/diff/ > > > Testing > --- > > > Thanks, > > Łukasz Wojniłowicz > >
[kmymoney4] [Bug 372254] Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 allan changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #6 from allan --- (In reply to NSLW from comment #5) > Based on comment #2: > Different CSV files structures (amount input vs debit/credit input) require > different importing profiles. It's not a bug if you import CSV file with > wrong import profile. That is obviously the case. However, if it results in a crash, is that also not a bug? I'm not happy to leave this so and am reopening the bug. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372166] CSV import not allowing choice of account for import on KF5.
https://bugs.kde.org/show_bug.cgi?id=372166 --- Comment #2 from allan --- (In reply to NSLW from comment #1) > It's not an bug, it's a feature to lessen user interaction. Look at last > Thomas' comment here https://git.reviewboard.kde.org/r/127920/ to get the > directions. > Feature can be improved or disabled through Settings->Configure > KMyMoney...->Plugins->CSV Importer configuration button and deselecting two > last checkboxes. Sorry, but it doesn't just lessen lessen user interaction, it prevents it by assuming that the required account name is contained within the file header, or possibly in a column. If this is not the case, the user needs to be able to specify the account in question. I don't think this bug should be closed as Invalid. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372234] CSV Import account selector malfunction on KF5
https://bugs.kde.org/show_bug.cgi?id=372234 --- Comment #3 from allan --- (In reply to NSLW from comment #2) > Account selector dialog is not part of CSV Importer, so setting appropriate > component. Of course I know that. However, I did not specify that it was a CSVimporter problem, and I classified it as 'general'. Are you able to confirm the problem? It seems that it is necessary to input sufficient characters to narrow down the choice to just one item which can then be selected. Also, the edit box loses focus, even though the cursor still appears in it. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 374352] Payee merge converts imported name containing string "Check" to existing Payee name "Check"
https://bugs.kde.org/show_bug.cgi?id=374352 --- Comment #4 from allan --- (In reply to Jack from comment #3) > Please note that the import is not changing any names, it is matching the > imported row to an existing payee - albeit not the one you want. As Allan > asked - check whether you have matching turned on for the "Check" payee. In > addition, I would even ask if you really want to have a payee named "Check"? > > Separately, things like "Transfer to Checking" and the others you listed do > not seem like payees at all, but more likely a Memo field. So - I wonder if > this is a problem with terminology. Unfortunately, my banks don't really have a concept of Payee, but tend to use the field more descriptively. Such entries as these are not uncommon. One can select to copy the payee field to the memo, but the matching still goes by the payee. Allan > Final point - when you do a CSV import, you have to specify which columns > contains the various fields. Until you can provide a sample csv file, and > state which columns you map to which fields for csv import, I have trouble > imagining that a column with "Transfer to Checking" really contains what you > want to match to a Payee. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 374352] Payee merge converts imported name containing string "Check" to existing Payee name "Check"
https://bugs.kde.org/show_bug.cgi?id=374352 --- Comment #2 from allan --- Also, would you say how you have setup matching for the troublesome payee/s. It may require some tuning. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 allan changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DOWNSTREAM -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 374082] Columns not wide enough - Date and Balance
https://bugs.kde.org/show_bug.cgi?id=374082 allan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from allan --- >> --- Comment #3 from Lenka Filova --- >> Ok, i received the help I needed. Thank you. >> Lenka I'll close this now. Oh, please post your replies on the bug report, is you would. Then there is a complete record there. Allan *** This bug has been marked as a duplicate of bug 342196 *** -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 --- Comment #15 from allan --- *** Bug 374082 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 --- Comment #14 from allan --- --- Comment #13 from Lenka Filova --- >> Hello Allan, >> thank you very much. >> have changed the fonts to system font and it helped!I really don´t know how >> to change the window width, so I´m happy the first option worked. >> Best wishes! >> Lenka Good, glad you're sorted. To change the window width, position your mouse cursor on the left or right window edge, and, with the left mouse button pressed, just drag the window width to give the columns more room. Then release the mouse button! That would be with your previous font setting. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 128874: Free QFileDialog memory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128874/#review101573 --- Did you get a solution to this problem? The reason I ask is that there is still a problem lurking in this area. Having selected a profile, I then go to select the file to import. Having got to the file selector, if I then decide instead to reverse to get a different profile, I cancel the file selector and am returned to the intro profile screen. If I cancel that too, when KMM is terminated, it aborts - Segmentation fault (core dumped). I've spent quite a bit of time on this, making sure everything that should be deleted, is deleted, but don't yet have a solution. As in this review, the Fileselect dialog is the crux, commenting it out avoids the abort. - Allan Anderson On Sept. 16, 2016, 4:38 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128874/ > --- > > (Updated Sept. 16, 2016, 4:38 p.m.) > > > Review request for KMymoney. > > > Repository: kmymoney > > > Description > --- > > After closing CSV Importer in the middle and then KMyMoney, I get "The > program has unexpectedly finished". > The problem doesn't occur if CSV Importer goes all way through to the last > page; then I can go back and close it wherever I want. > If I comment out this line, there is no problem at all. > ```c++ > QPointer dialog = new QFileDialog(this, QString(), > fileInfo.absoluteFilePath(), > i18n("*.csv *.PRN *.txt | > CSV Files\n *|All files")); > ``` > Memory on which dialog pointed wasn't deleted in the method and it obviously > need to be deleted, but the problem remains. Does anyone know how to prevent > QtCreator from showing "The program has unexpectedly finished" here? > > > Diffs > - > > kmymoney/plugins/csvimport/csvwizard.h ecec5b0 > kmymoney/plugins/csvimport/csvwizard.cpp b576dea > > Diff: https://git.reviewboard.kde.org/r/128874/diff/ > > > Testing > --- > > > Thanks, > > Łukasz Wojniłowicz > >
[kmymoney4] [Bug 372547] Unable to load some investments on KF5
https://bugs.kde.org/show_bug.cgi?id=372547 --- Comment #4 from allan --- (In reply to NSLW from comment #3) > Hi Allan, > As stated earlier, filter lineedits weren't essential to import so they were > removed. If you used them to manually enter name and symbol of securities, > then their name should be appropriate. If your investment import files contain the security information in columns, then yes, the line edit for the security name is not needed, as you say. However, that's not my situation. In my case, the security name is on one of the several header rows, so it has to be entered manually. Therefore it is essential to have the line edit restored. > In current situation I suggest separate dialog for manually entering name > and symbol of security which would pop up during transition to next wizard > page in case name and symbol combobox would be empty. I don't need it right > now and there is still workaround. > Cheers > Łukasz I've reorganised the UI to accommodate this. I tried having an additional row, but that made the appearance too dissimilar to the other wizard pages, so what I've done is move the comboboxes about to make room, while trying to keep associated fields close together. I don't really like the idea of a supplementary window to catch 'forgotten bits.' -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 374082] Columns not wide enough - Date and Balance
https://bugs.kde.org/show_bug.cgi?id=374082 --- Comment #1 from allan --- Are you able to stretch the window horizontally, and does that help? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 --- Comment #12 from allan --- (In reply to Lenka Filova from comment #9) > Hello, > > I have the same problem as Dino. Nevertheless, on this page I could not find > any solution to it. > > Is there a way how to solve it? I use Windows 10 and the latest version of > Kmymoney 4.8.0. > > Thank you! Would you, too, also say if my comments to Dino help you in any way. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 --- Comment #11 from allan --- Also, would you say if stretching the window width helps, or not. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 342196] Register page, the colum of Date and Balance are not wide enough, only shown 3 digits + 2 decimal
https://bugs.kde.org/show_bug.cgi?id=342196 --- Comment #10 from allan --- (In reply to Dino from comment #8) > Created attachment 91932 [details] > MyMoney05.jpg > > 1) should be system fonts, never changed fonts type (see attached image) > > 2) Yes, I use the transaction form. > > > > > > Il 07/04/2015 14:44, Cristian Oneț ha scritto: > > https://bugs.kde.org/show_bug.cgi?id=342196 > > > > --- Comment #6 from Cristian Oneț --- > > The column width can't be modified because it's managed by the application, > > in > > the case of the attached screenshots the automatic calculation have failed. > > To > > pinpoint the problem I have to ask a few more questions: > > > > 1. Do you use system fonts or custom fonts? > > > > https://docs.kde.org/stable/en/extragear-office/kmymoney/details.settings.fonts.html > >MyMoney05.jpg > > 2. Do you use the transaction form? > > > > https://docs.kde.org/stable/en/extragear-office/kmymoney/details.settings.register.html > > This screen-shot, MyMoney05.jpg, shows that you are not using system fonts as the appropriate check-box (top left) is unchecked. Please say if changing that helps, or otherwise. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349938] hang freeze during QIF import
https://bugs.kde.org/show_bug.cgi?id=349938 --- Comment #24 from allan --- OK, that's good to know. At the moment, I'm suspecting that this is an issue with how Windows handles these file name characters. It may be possible, given developer time availability, that a work around could be provided. The timescale, however, is not short, as developer time is in short supply, and the big priority at the moment is the port of KMyMoney to Frameworks5. So far as the date format is concerned, KMM attempts to derive the format from the actual data. However, because of the ambiguity of day and month values, it is not always possible to determine this absolutely so that is when the query occurs, which only the user can do. I'm not sure, though, however, whether in such cases, the stored date format could be used, or even whether it is used. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349938] hang freeze during QIF import
https://bugs.kde.org/show_bug.cgi?id=349938 --- Comment #22 from allan --- (In reply to Antoine T from comment #21) > (In reply to allan from comment #20) > > Just saw your commment about the ',', and I have tried that, both in a file > > name and in a directory, again without problem, I'm afraid. > > > > Allan > > Have you tried in Windows or Linux? Sorry, but I'm Linux only. Perhaps a Windows user could do this small test. How confident are you that the ',' issue resolves your problem? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349938] hang freeze during QIF import
https://bugs.kde.org/show_bug.cgi?id=349938 --- Comment #20 from allan --- Just saw your commment about the ',', and I have tried that, both in a file name and in a directory, again without problem, I'm afraid. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349938] hang freeze during QIF import
https://bugs.kde.org/show_bug.cgi?id=349938 --- Comment #19 from allan --- The small test file still imports without problem here. In comment #12, there is mention of a problem with an error message window being overlaid with other windows. Can you try that, moving superimposed windows out of the way or closing them? I can't think of any way to fix a problem that I can't reproduce, sadly. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 373431] automatic ledger change
https://bugs.kde.org/show_bug.cgi?id=373431 --- Comment #1 from allan --- It sounds like to get around the problem, you make two changes at the same time, or more. You use your backup file on a different PC running a different distro. What might be more informative is if you were able to transfer your backup file (or a copy of), to your first PC and see if that works. If so, it might indicate a problem with your original file. Generally, any errors that show on saving are from the consistency check, and are not necessarily related to the current operations, but are often historic, from original file creations. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372254] Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 --- Comment #4 from allan --- (In reply to allan from comment #1) > (In reply to allan from comment #0) > > The crash of KMM seems to happen every time, at least with one particular > > account. I get Segmentation fault (core dumped) > > but with no other detail. > > The Segmentation fault (core dumped) is not related to this problem, but > seems to occur whenever KMM is closed. In connection with this crash on exiting, which happens every time, I've just noticed a little more detail, which I had not noticed previously. "QXcbConnection: XCB error: 3 (BadWindow), sequence: 19563, resource id: 35699775, major code: 40 (TranslateCoords), minor code: 0 Segmentation fault (core dumped) " It means little to me, but most likely one of the devs will have a clue. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372786] New: Can't import some investments on KF5
https://bugs.kde.org/show_bug.cgi?id=372786 Bug ID: 372786 Summary: Can't import some investments on KF5 Product: kmymoney4 Version: git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- On completing the CSV importer fields/columns, when I clicked Import, the account selector showed only checking accounts. This is the result of a recent code change circa line 646 in MyMoneyStatementReader::processTransactionEntry() - " if (brokerageactid.isEmpty()) { brokerageactid = SelectBrokerageAccount(); }" as it supplies a checking account for the investment account import. On removing this code change, the import completed, but without any account selection being offered. In my case, KMM choses to import into an account which happens to be closed. The user needs to be able to select the account into which to import, as a security/stock could be present in more than one investment account. The importing CSV file cannot know what the user requires. To avoid importing into a closed account, I've added a test for closed accounts circa line 468 in csvwizard() - "if ((statementHeader.contains(txt, Qt::CaseInsensitive)) && (!(*account).isClosed()))" The import now proceeds and produces the account selection dialog, as required. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372764] New: Closed accounts not shown in KF5
https://bugs.kde.org/show_bug.cgi?id=372764 Bug ID: 372764 Summary: Closed accounts not shown in KF5 Product: kmymoney4 Version: git (master) Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- Accounts view doesn't show closed accounts, but they are visible in Institutions view and also in Edit> Find transaction. This became apparent when I'd imported an investment file but couldn't find the transactions. 'Do not show closed accounts is not checked'. 'Show equity accounts' is checked. As the account showed in Institutions view, I reopened the account and it then showed in Accounts view, but when I closed it again, it disappeared instead of showing as 'closed'. This is on Version 4.100.0-64d8749. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372547] Unable to load some investments on KF5
https://bugs.kde.org/show_bug.cgi?id=372547 --- Comment #2 from allan --- @ lukasz.wojnilow...@gmail.com Hi Łukasz/Anyone, Do you have any interest in resolving this issue? I've had a first go at restoring the widgets that were removed and have had to reorganise some of the others, trying to keep together those logically related. If you are still interested, I can add attachments here. I've not had time/opportunity to look into revising the coding. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372547] Unable to load some investments on KF5
https://bugs.kde.org/show_bug.cgi?id=372547 --- Comment #1 from allan --- See Review Request 129003: Separate investment page item 6). 23 September. 6) removed name and security filter lineedits, because they aren't essential/usefull to import, These fields are essential should the input file (eg. Fidelity UK) not have columns for these fields. I have only recently been able to try rev 4.100. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372547] New: Unable to load some investments on KF5
https://bugs.kde.org/show_bug.cgi?id=372547 Bug ID: 372547 Summary: Unable to load some investments on KF5 Product: kmymoney4 Version: git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- When the import file has been loaded, one needs to select the appropriate columns for the various fields. However, some investment files do not have columns for the symbol and security name. In these cases, instead one entered those details into edit boxes. This is no longer possible as recently the edit boxes have been removed. These need to be reinstated, please. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372507] QIF importer fails to list all accounts
https://bugs.kde.org/show_bug.cgi?id=372507 allan changed: What|Removed |Added Component|onlinebanking |general --- Comment #2 from allan --- Online banking is something else again. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372507] QIF importer fails to list all accounts
https://bugs.kde.org/show_bug.cgi?id=372507 --- Comment #1 from allan --- That sounds very much like the same problem reported several times for the CSV importer. It's fixed in the next stable release. There's no date for that as yet as it depends on porting KMyMoney to KDE Frameworks 5 which is a biggish job. What I've done is to import into a checking account, select all those transactions and transfer them to their intended account. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372254] Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 --- Comment #3 from allan --- Totally unconnected, but I previously reported that I'd noticed the following - "QObject::connect: No such signal FormatsPage::statementReady(MyMoneyStatement&) QObject::connect: (sender name: 'FormatsPage') QObject::connect: (receiver name: 'csvimport') KMyMoneyPlugin::KMMStatementInterface::import start Updating account in MyMoneyStatementReader::startImport failed Importing statement for '' Importing statement for '' done QObject::connect: No such signal FormatsPage::statementReady(MyMoneyStatement&) QObject::connect: (sender name: 'FormatsPage') QObject::connect: (receiver name: 'csvimport') KMyMoneyPlugin::KMMStatementInterface::import start" A single line needed to be edited, which I've done in the code for this bug. Do I need to raise a separate bug or add it to this one? I can add the two fixes as an attachment here. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372254] Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 --- Comment #2 from allan --- I think I can see what has happened. I have created a profile for one of my banks, but I have more than one account there. The checking account has one column for the Amount, whereas the savings account has columns for both credits and debits. The latter therefore has more columns, and the column numbers from this account were saved in the resource file. If now a checking account is loaded, the saved column details will include more columns than in the checking file. Therefore, the result is that an attempt is made to access a nonexistent column, and an out-of-bounds index is generated. This happens circa line 576-578 in bankingwizardpage.cpp - if (!memo.isEmpty()) memo.append(QChar(QLatin1Char('\n'))); memo.append(m_columnList[m_wiz->m_memoColList[i]]); I have inserted if (m_wiz->m_memoColList[i] < m_columnList.count()) // avoid out of bounds before the last line to avoid it going out of bounds. This avoids the problem, but an additional profile will be needed to cover the different formats. Has anyone else a more elegant solution? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372254] Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 --- Comment #1 from allan --- (In reply to allan from comment #0) > The crash of KMM seems to happen every time, at least with one particular > account. I get Segmentation fault (core dumped) > but with no other detail. The Segmentation fault (core dumped) is not related to this problem, but seems to occur whenever KMM is closed. The main problem here was triggered by resource file content for this account, which I have now removed. What actually caused the crash looks to be an out of bounds index, but unfortunately I'm not familiar with the logic here. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372254] New: Crash when importing CSV file
https://bugs.kde.org/show_bug.cgi?id=372254 Bug ID: 372254 Summary: Crash when importing CSV file Product: kmymoney4 Version: git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- The crash of KMM seems to happen every time, at least with one particular account. I get Segmentation fault (core dumped) but with no other detail. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372234] CSV Import account selector malfunction on KF5
https://bugs.kde.org/show_bug.cgi?id=372234 --- Comment #1 from allan --- KMyMoney Version 4.100.0-e36687e -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372234] New: CSV Import account selector malfunction on KF5
https://bugs.kde.org/show_bug.cgi?id=372234 Bug ID: 372234 Summary: CSV Import account selector malfunction on KF5 Product: kmymoney4 Version: git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- When I am importing a CSV file and get to the account selector dialog, multiple accounts show, as expected, but not all of them. So, I have to scroll to display the required name. Unfortunately, any click in the window, other than on one of the names, causes the scroll list drop-down to disappear. It is necessary to enter a few matching characters into the edit box to get the required account to show in the drop-down. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372163] Investment sells giving the wrong result
https://bugs.kde.org/show_bug.cgi?id=372163 --- Comment #2 from allan --- See Bug 345655 - Rounding problems between checking and investment account. This was fixed in 4.8.0, so it might be worthwhile upgrading to see if it is your problem. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 372166] New: CSV import not allowing choice of account for import on KF5.
https://bugs.kde.org/show_bug.cgi?id=372166 Bug ID: 372166 Summary: CSV import not allowing choice of account for import on KF5. Product: kmymoney4 Version: git (master) Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Target Milestone: --- When I imported a CSV file (or tried to), I went through the set-up, but on clicking Import, I didn't get the account selector, but did get the Statement stats screen, which seemed to be indicating a successful import. However, the account into which I had intended to do the import showed no sign of the data. After doing a search, I found the import had gone to a different account altogether. This account is a temporary credit card account I created when it was not possible to import into credit card accounts, even the file being imported was for a checking account. The data went into a credit card account named cc. I've looked at the code, but it has been much rewritten lately, and I'm unfamiliar with it, so it's possible that what follows is wrong. However... in bool CSVWizard::detectAccount(MyMoneyStatement& st), circa line 523, accounts = findAccounts(accountTypes, statementHeader) gets loaded with the first line of data - "Date, Type, Description, Value, Balance, Account Name, Account Number". What then seems to happen is that that line is scanned for a possible account name for the import, but there is none. However, there are two strings - Account Name" and "Account Number", which contain a valid account name, "cc" in my .kmy file. So, on the basis of a line of data happening to contain part of a string that matches an account name, the data is imported into a completely unconnected account. To confirm this suspicion, I changed the two strings in the header line to "Name" and "Number", and the file then imported correctly. I'm unsure about the validity of the logic here, apparently hoping to match data imported from a bank with an account name that the user has invented, totally unbeknown to the bank. Totally unconnected, but I also noticed in that area also that circa line 513, accountTypes MyMoneyAccount::Checkings, MyMoneyAccount::Savings and MyMoneyAccount::Liability are duplicated, but apparently harmlessly. -- You are receiving this mail because: You are the assignee for the bug.
Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5
Sorry, it was the duplication 'Aa' I was referring to. It jumps out at me so I didn't make it clearer.Allan Sent from my Samsung device Original message From: Ralf Habacker Date: 03/11/2016 07:24 (GMT+00:00) To: kmymoney-devel@kde.org Subject: Re: More libalkimia problems/questions was: problems compiling 4.8 on system with both qt4 and qt5 Am 03.11.2016 um 00:25 schrieb aga: > I don't know if this is/these are typos or deliberate, or even if > they're important, or fixed already, but, in this chunk, there are four > LibAalkimiaxx's. These are two variants to show how it could be performed: variant 1: > if(QT4_FOUND) >> find_package(LibAalkimia4) >> if(NOT LIBALKIMIA4_FOUND) [1] >> find_package(LibAalkimia) >> endif() >> else() >> find_package(LibAalkimia5) >> endif() [1] for alkimia 4.3.2 package variant 2 (without search for old alkimia package) >> >> if(QT4_FOUND) >> set(QT_SLOT 4) >> else() >> set(QT_SLOT 5) >> endif() >> >> find_package(LibAalkimia${QT_SLOT}) Ralf
Re: alkimia yet again - on KF5
Thanks Cristian. I have already built it from git but couldn't see, yet, how to integrate it.Allan Sent from my Samsung device Original message From: Cristian Oneț Date: 25/10/2016 19:08 (GMT+00:00) To: For KMyMoney development Subject: Re: alkimia yet again - on KF5 Yes, build libalkimia [1] and use it instead of the one provided by your system. [1] https://quickgit.kde.org/?p=alkimia.git 2016-10-25 20:53 GMT+03:00 aga : > After many attempts, I think I'm getting close, but I now need Alkimia >>= 6 and haven't yet found a source, after several hours. My distro has > only rev 5. > > Can someone point me in the right direction please. Thanks. > > Allan >
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #9 from allan --- (In reply to Thomas Baumgart from comment #8) > I tried this on my KDE4, KMyMoney 4.8 production system (this is generated > of HEAD on the 4.8 branch). > When I change the encoding in the dialog to UTF-16 before I select the file, > then things seem to work properly. Just to be clear, are you saying that you do not then see the problem I reported, of the data being garbled? If I ensure that UTF-16 is already selected - displayed in the file selector - then I definitely do see the corruption. > I am looking at the following snippet in > CSVDialog::readFile(const QString& fname): Might this be a non-current git head version? There has recently been some reformatting of the source and I have void CSVWizard::readFile(const QString& fname), as does the current git head. In terms of the actual code, they are identical in this particular area. Just to be clear, again. So far as the selector is concerned, then, yes, there are a couple of problems, although if the decoding is for UTF-16, from previous activity or from setting it prior to selecting the file, then the file should have the required encoding. Some tweaking looks to be necessary though. Allan > > QFile m_inFile(m_inFileName); > m_inFile.open(QIODevice::ReadOnly); // allow a Carriage return - // > QIODevice::Text > QTextStream inStream(&m_inFile); > QTextCodec* codec = > QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum()); > inStream.setCodec(codec); > > QString buf = inStream.readAll(); > > When selecting UTF-16 before selecting your file, QString buf contained the > correct data. I verified this in the debugger and also data displayed in > spread sheet form seemd to be correct. > > Hope that helps for further investigation. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #7 from allan --- [from Thomas] " Hi Allan, you found out yourself: the BOM is not wrong, it's missing. I am sure, you stumbled over https://en.wikipedia.org/wiki/UTF-16. I have not looked at the code of the CSV importer at that point, but you could check the beginning of the file (4 bytes) and see if the first two match a BOM or you find two 0x00 in those four bytes (where that would probably not work for Asian countries as they fill the upper byte with their characters). Reading the data through a QTextStream allows to setup the encoding/decoding. Please take a look at QTextStream::setCodec() and setAutoDetectUnicode(), though according to the docs I have, the automatic detection should be the default. Maybe, you add another UI selector for the Encoding, in case you don't have it. See QTextCodec::availableCodecs() for a list of them. Check Kate/Kwrite in the Tools/Encding menu how this may look like. So much for now. If you don't get the codec stuff going, please tell me where to find the relevant source code and I take a look at it. Thomas" [My reply] " I have /had - QTextStream inStream(&inFile); QTextCodec* codec = QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum()); inStream.setCodec(codec); QString buf = inStream.readAll(); ... (void CSVWizard::readFile(const QString& fname) line c843) which I nicked from Qt, I think. I have encoding selection in the file selector. ... QPointer label = new QLabel(i18n("Encoding")); dialog->layout()->addWidget(label); //Add encoding selection to FileDialog QPointer comboBoxEncode = new QComboBox(); setCodecList(m_codecs, comboBoxEncode); comboBoxEncode->setCurrentIndex(m_encodeIndex); connect(comboBoxEncode, SIGNAL(activated(int)), this, SLOT(encodingChanged(int))); dialog->layout()->addWidget(comboBoxEncode); (bool CSVWizard::getInFileName(QString& inFileName) line c798) I don't see a setAutoDetectUnicode(). I don't think I had auto-selection, but encoding was by manual selection from the list of codecs, but UTF-16 seems not to work. (in my code). Allan" I'm afraid I'm not able to commit to coding, still. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #5 from allan --- Thomas suggested using Okteta to look at the data to see if the BOM was correct. Here are the first few lines :- " 22 00 4D 00 52 00 20 00 41 00 4C 00 ".M.R. .A.L. 000C 4C 00 41 00 4E 00 20 00 41 00 4E 00 L.A.N. .A.N. 0018 44 00 45 00 52 00 53 00 4F 00 4E 00 D.E.R.S.O.N. " So, no BOM, just the data, and still mis-formatted by the plugin. Ah, I've just checked against the Libre Office Calc file and, just looking at the beginning, the bad one has "22 00", and the good one has "FF FE". So, the BOM is wrong on the bank version. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #4 from allan --- (In reply to allan from comment #3) > It looks like my attempts to provide an edited sample file either produce > rubbish, or remove whatever causes the problem. > So, I may have to provide a complete file, but I don't wish to broadcast it, > so would like to send it off-line. To whom? > > Allan I've sent a gpg'ed copy to Thomas. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371180] New: A request for an additional monetary format
https://bugs.kde.org/show_bug.cgi?id=371180 Bug ID: 371180 Summary: A request for an additional monetary format Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Apart from the unusual date format, I have a further complication. A credit to the credit card company now produces the following format - "06 Sep","AMAZON UK RETAIL AMAZO AMAZON.CO.UK LUX","£27.50","CR", The plugin did have a similar capability, but I think this has very recently been removed. It would be very helpful if this format could be handled. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371177] New: Request for additional date format - no year!
https://bugs.kde.org/show_bug.cgi?id=371177 Bug ID: 371177 Summary: Request for additional date format - no year! Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com My new format credit card statement causes further problems. It produces a date with no year, like "15 Aug". To avoid an on-going need to edit every entry, it would be good if the CSV importer could cope with this format, please. Thanks Allan Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #3 from allan --- It looks like my attempts to provide an edited sample file either produce rubbish, or remove whatever causes the problem. So, I may have to provide a complete file, but I don't wish to broadcast it, so would like to send it off-line. To whom? Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 allan changed: What|Removed |Added Attachment #101617|0 |1 is obsolete|| --- Comment #2 from allan --- Created attachment 101618 --> https://bugs.kde.org/attachment.cgi?id=101618&action=edit UTF-16 file -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #1 from allan --- Created attachment 101617 --> https://bugs.kde.org/attachment.cgi?id=101617&action=edit UTF-16 file -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] New: CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 Bug ID: 371069 Summary: CSV plugin mishandles UTF-16 files Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com My credit card company has revised their web site, and the statement importing procedure and format has changed. The KMM CSV importer is not happy with this new format. All characters have an interspersed null character (I think, probably 00). Each line is followed by an additional line containing the same odd character. So, the import is incorrect. If I import via Libre Office Calc, all is correct. It is shown as UTF-16. If I load via Kate, this too looks wrong, unless I change the encoding from UTF-8 to UTF-16. In the CSV importer, however, changing the encoding from UTF-8 to UTF-16 makes no apparent difference and the original incorrect result still appears. Reloading an earlier file is as normal. So, it appears that the import encoding has changed and the CSV plugin does not handle it correctly. Reproducible: Always Steps to Reproduce: 1. Import a CSV file encoded in UTF-16. 2. The file will show the incorrect format. 3. Actual Results: As above. Expected Results: The UTF-16 should be handled correctly. There may be more to this, however. When I tried to create a file in UTF-16, it could be imported correctly. So, to be able to demonstrate the problem, I have used a file from my credit card company, deleted everything except the first line and then added a new first line of "12-10-2016,Description,1234.56" Attachment follows. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 368593] KmyMoney File Not opening and gives error As " Please use an older version...."
https://bugs.kde.org/show_bug.cgi?id=368593 --- Comment #7 from allan --- I fear not. If you have no backup, then there is nothing from which to recover. At least, now, do make sure you have enabled automatic backups - Settings>Configure KMyMoney>General>Global. In addition, however, make a practice of saving a copy file each time you finish a session. A possibly forlorn hope or two, however. Do a file search of your system for *.kmy and *.kmy.* files. Also, just in case your file is only partially corrupted, open your file in KMM , then Save as, and set the filter there to XML files. Then, open that file in your browser, Firefox or whatever and look through the file to see if you can recognise any data as your missing data, hoping that perhaps just the beginning of the file is corrupted. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 128878: Add slotSaveAsQIFClicked to CSV Importer
> On Sept. 11, 2016, 10:09 a.m., Allan Anderson wrote: > > It was actually on my todo list to remove the QIF facility as it no longer > > had any purpose. It was a relict from early days before CSV import became > > fully established. > > I had indicated this on the lists several times without receiving any > > protests. It's possible, I suppose, that on implementation, a non-lister > > might discover that a much needed feature had been removed. I would still > > have gone ahead, but the change would have had to be reverted in that > > circumstance. > > Perhaps you see a need? > > Łukasz Wojniłowicz wrote: > I didn't know that you wanted to remove QIF facility. I don't use it > personally. Initially I wanted to move it as separate CSV->QIF converter but > it would involve the same steps you do during CSV import, so I left it where > it is. > I think defeaturing CSV importer of QIF converter would be loss of work. > > Allan Anderson wrote: > It's certainly not causing any harm, that I'm aware of. It was purely to > remove clutter. No hard views, either way, though. > > Łukasz Wojniłowicz wrote: > We can hide it deep with an option through recent configuration dialog to > remove clutter, if all you devs think it would be a good idea :) > > Allan, do you use CSV Importer from master branch? Lots of code have been > changed recently and I'm little bit concerned about usablity in all cases. I'm afraid I have not had a lot of time lately, what with my hospital appointments, dental troubles and now my wife was admitted to hospital 10 days ago. Also, I've been waiting on my distro, and as it happens only two days ago it released a new version. As soon as I can find time, I'll try to upgrade, etc. - Allan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128878/#review99081 --- On Sept. 10, 2016, 4:35 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128878/ > --- > > (Updated Sept. 10, 2016, 4:35 p.m.) > > > Review request for KMymoney. > > > Repository: kmymoney > > > Description > --- > > 1) It's now possible to save qif file with investments, > 2) If account is available, then it will be added to qif file, > 3) If type of import is available, then it will be added to qif file, > 4) Handled canceling of QFileDialog, > 5) QFileDialog saves only .qif files now, > 6) Date format is hardcoded to MM/dd/, because it is so in files, that I > saw. > > > Diffs > - > > kmymoney/plugins/csvimport/csvdialog.h 3cedd92 > kmymoney/plugins/csvimport/csvdialog.cpp 556d1c5 > kmymoney/plugins/csvimport/csvwizard.h 48c15ea > kmymoney/plugins/csvimport/csvwizard.cpp fcf73fd > kmymoney/plugins/csvimport/investprocessing.h 6ca2e53 > kmymoney/plugins/csvimport/investprocessing.cpp 7499b10 > > Diff: https://git.reviewboard.kde.org/r/128878/diff/ > > > Testing > --- > > > Thanks, > > Łukasz Wojniłowicz > >
Re: Review Request 128878: Add slotSaveAsQIFClicked to CSV Importer
> On Sept. 11, 2016, 10:09 a.m., Allan Anderson wrote: > > It was actually on my todo list to remove the QIF facility as it no longer > > had any purpose. It was a relict from early days before CSV import became > > fully established. > > I had indicated this on the lists several times without receiving any > > protests. It's possible, I suppose, that on implementation, a non-lister > > might discover that a much needed feature had been removed. I would still > > have gone ahead, but the change would have had to be reverted in that > > circumstance. > > Perhaps you see a need? > > Łukasz Wojniłowicz wrote: > I didn't know that you wanted to remove QIF facility. I don't use it > personally. Initially I wanted to move it as separate CSV->QIF converter but > it would involve the same steps you do during CSV import, so I left it where > it is. > I think defeaturing CSV importer of QIF converter would be loss of work. It's certainly not causing any harm, that I'm aware of. It was purely to remove clutter. No hard views, either way, though. - Allan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128878/#review99081 --- On Sept. 10, 2016, 4:35 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128878/ > --- > > (Updated Sept. 10, 2016, 4:35 p.m.) > > > Review request for KMymoney. > > > Repository: kmymoney > > > Description > --- > > 1) It's now possible to save qif file with investments, > 2) If account is available, then it will be added to qif file, > 3) If type of import is available, then it will be added to qif file, > 4) Handled canceling of QFileDialog, > 5) QFileDialog saves only .qif files now, > 6) Date format is hardcoded to MM/dd/, because it is so in files, that I > saw. > > > Diffs > - > > kmymoney/plugins/csvimport/csvdialog.h 3cedd92 > kmymoney/plugins/csvimport/csvdialog.cpp 556d1c5 > kmymoney/plugins/csvimport/csvwizard.h 48c15ea > kmymoney/plugins/csvimport/csvwizard.cpp fcf73fd > kmymoney/plugins/csvimport/investprocessing.h 6ca2e53 > kmymoney/plugins/csvimport/investprocessing.cpp 7499b10 > > Diff: https://git.reviewboard.kde.org/r/128878/diff/ > > > Testing > --- > > > Thanks, > > Łukasz Wojniłowicz > >
Re: Review Request 128878: Add slotSaveAsQIFClicked to CSV Importer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128878/#review99081 --- It was actually on my todo list to remove the QIF facility as it no longer had any purpose. It was a relict from early days before CSV import became fully established. I had indicated this on the lists several times without receiving any protests. It's possible, I suppose, that on implementation, a non-lister might discover that a much needed feature had been removed. I would still have gone ahead, but the change would have had to be reverted in that circumstance. Perhaps you see a need? - Allan Anderson On Sept. 10, 2016, 4:35 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128878/ > --- > > (Updated Sept. 10, 2016, 4:35 p.m.) > > > Review request for KMymoney. > > > Repository: kmymoney > > > Description > --- > > 1) It's now possible to save qif file with investments, > 2) If account is available, then it will be added to qif file, > 3) If type of import is available, then it will be added to qif file, > 4) Handled canceling of QFileDialog, > 5) QFileDialog saves only .qif files now, > 6) Date format is hardcoded to MM/dd/, because it is so in files, that I > saw. > > > Diffs > - > > kmymoney/plugins/csvimport/csvdialog.h 3cedd92 > kmymoney/plugins/csvimport/csvdialog.cpp 556d1c5 > kmymoney/plugins/csvimport/csvwizard.h 48c15ea > kmymoney/plugins/csvimport/csvwizard.cpp fcf73fd > kmymoney/plugins/csvimport/investprocessing.h 6ca2e53 > kmymoney/plugins/csvimport/investprocessing.cpp 7499b10 > > Diff: https://git.reviewboard.kde.org/r/128878/diff/ > > > Testing > --- > > > Thanks, > > Łukasz Wojniłowicz > >
[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)
https://bugs.kde.org/show_bug.cgi?id=272398 --- Comment #8 from allan --- (In reply to Dennis Gallion from comment #7) > Thank you Allan for the very quick reply. As it turns out, 4.8.0-13.3 was > just added this morning to the openSUSE 13.2 KDE:Extra unsupported > repository. I installed it and good news the cpu spike and delay in posting > ledger transactions has apparently been fixed. Thanks! > > However, I noted in the Change Log for 4.8.0 the following: > > * Categories no longer have opening date, which caused annoyingerrors both > during input and while running the consistency check > * Fixed some annoying consistency check errors > > When I ran 4.8.0 the first time, and each time the file is saved, the > Consistency Check is run and it is returning over uncorrectable 5000 errors, > each indicating a posting date that is older than the opening date of the > account. All of the transaction data in the log is for 2007 and older; I > can't say if there are such errors in newer data. It may be that most of > the errors are in data that was imported, but for a certainty I began using > the application after the import in about 2005 so there are errors in at > least some newer data. The fix was specific to categories having an opening date. You may still have other accounts with problem dates, I'm afraid. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)
https://bugs.kde.org/show_bug.cgi?id=272398 --- Comment #6 from allan --- I can't really see any prospect of attempting to fix a problem on such an old release. Please, can't you upgrade to a current version? 4.7.2 includes numerous bug fixes, and 4.8.0 was released quite recently. If the problem is still present, then there is a far better prospect of finding a fix. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362373] layout seems to be changed to TXT mode, losing HTML formats
https://bugs.kde.org/show_bug.cgi?id=362373 allan changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #2 from allan --- (In reply to CPL from comment #1) > Even with 4.8 version, the problem still remains. Oh, well 4.8.0 is only very recently released, with no such problem showing up.. So, we need to consider your .kmy file. Would you create a new, minimal .kmy file and see if that fares any better. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #32 from allan --- Ah, we're on reconciliation. It is indicating a discrepancy with cleared transactions. Uncleared transactions will be excluded from reconciliation. So, in that account, click Not marked in the status (top right). Make sure all those transactions are cleared. It might help in any further difficulty to just reconcile part of the account, into smaller chunks , if that helps to show where the problem lies. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #30 from allan --- I made an assumption that it could be the date field that was red. Obviously now that's not the issue. So, I'm missing something. Are you able to attach a screen-shot to the bug? Allan In Settings/Configure KMM/Colors, a negative value may be set to show as red. Might that explain? -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 128511: Move displayLine to CSVWizard
> On July 24, 2016, 10:54 a.m., Thomas Baumgart wrote: > > Again, just visual inspection. Looks good to me besides the two little > > nitpicks. Someone with more knowledge about the functionality should check > > as well. If that includes me, then I agree. - Allan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128511/#review97792 --- On July 24, 2016, 9:07 a.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128511/ > --- > > (Updated July 24, 2016, 9:07 a.m.) > > > Review request for KMymoney. > > > Repository: kmymoney > > > Description > --- > > Purpose of displayLine in tableWidget shouldn't differ whether it's > investment or banking statement, so take of responsibilities of parsing > data into columns and creating memo field from displayLine and put them > into separate functions. > > In csvdialog.cpp and investprocessing.cpp, I introduced createMemoField (it > simplifies memo concatenating and allows to remove some redundant boolean > variables), which in both places looks the same. I think it will be easy to > move it into csvwizard.cpp after trying to move e.g. readFile there, so that > will be next target. > > > Diffs > - > > kmymoney/plugins/csvimport/csvdialog.h 69cca6e > kmymoney/plugins/csvimport/csvdialog.cpp fa70b04 > kmymoney/plugins/csvimport/csvwizard.h 28eea62 > kmymoney/plugins/csvimport/csvwizard.cpp 7aee196 > kmymoney/plugins/csvimport/investprocessing.h 38f622c > kmymoney/plugins/csvimport/investprocessing.cpp 328a79b > > Diff: https://git.reviewboard.kde.org/r/128511/diff/ > > > Testing > --- > > Banking and investment statement CSV imports; with and without setup. > > > Thanks, > > Łukasz Wojniłowicz > >
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #28 from allan --- Actually, if the answer to the previous comment does not resolve the issue, it would be as well to open a new bug, as your problem is not to do with rounding. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #27 from allan --- (In reply to sven.keller from comment #25) > Hi Folks, > eventually I got the RPM package provided by Opensuse. > I can confirm, for my "productive" file it is not working as expected. > Great work! Thanks a lot for the effort! > > However one question remains (but perhaps not related to this bug) > I double checked and corrected all my investment transactions and the > (visible) amount of the account also matches the amount downloaded from the > bank. > However it is marked in red as if it would not match? > Is there a way to check where a potential mismatch might be? > > Cheers > > Sven Can you be a bit more precise? Is it just the date field? If you hover the pointer, does that produce a clue? Might it be that the opening date for the account is after the transaction date? If so, edit the account's opening date to match the oldest likely transaction. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364425] CSV import only shows checking accounts when selecting Banking
https://bugs.kde.org/show_bug.cgi?id=364425 allan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from allan --- (In reply to NSLW from comment #1) > Git commit 9c5397238947c8a010eb2e0939cb34d729dfb751 by Łukasz Wojniłowicz. > Committed on 18/06/2016 at 17:16. > Pushed by wojnilowicz into branch '4.8'. > > Set type of banking statement to unknown during CSV import > > Type of banking statement shouldn't be set to 'checkings' by default, > bacause statement to be imported could be 'checking' but also 'credit > card'. > > M +1-2kmymoney/plugins/csvimport/csvdialog.cpp > > http://commits.kde.org/kmymoney/9c5397238947c8a010eb2e0939cb34d729dfb751 Credit card imports still do not work on 4.8.0. The fix "Thanks for the files. As I wrote before, CSV should be already fixed in upcoming KMM 4.8.1. Something is wrong with QIF importer in KMM, because file has correct type "!Type:CCard" and its account type is being incorrectly recognized. That needs to be fixed. As temporary fix you can use workaround provided by Allan Anderson https://mail.kde.org/pipermail/kmymoney-devel/2016-June/016810.html"; should be present in 4.8.1. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365802] Cannot import into Credit-Card Account
https://bugs.kde.org/show_bug.cgi?id=365802 --- Comment #1 from allan --- I reported this problem a few weeks ago. It's the result of a recently introduced fix. It is possible to get round this by importing your credit card file into a temporary checking account. Then, select all those transactions, right click and select move transaction to... your atual credit card account. There is a full fix in the offing. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365307] Download
https://bugs.kde.org/show_bug.cgi?id=365307 --- Comment #4 from allan --- Also, if you can reproduce your problem, please supply the url which is displaying the invalid link, so that it can be attended to. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365307] Download
https://bugs.kde.org/show_bug.cgi?id=365307 --- Comment #2 from allan --- James, you do not have to register to obtain the download. It looks like you may have been attempting to download from an incorrect link. I'll cc. you in case you are not subscribed to this list, just in case that hasn't happened. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365023] Payee listing
https://bugs.kde.org/show_bug.cgi?id=365023 --- Comment #1 from allan --- A bit more information might help us. It sounds like you may be importing? If so, by what method? What revision of KMyMoney are you using? (Help>About KMM). Distro package or compiled from source? Have you considered setting up matching for the payee name you wish to use? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 allan changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from allan --- I know you are all up to your eyebrows, and doing fantastic work I've just reopened this to ensure it is not overlooked, as there is still, I think, an outstanding issue. https://bugs.kde.org/show_bug.cgi?id=345655#c23. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #14 from allan --- (In reply to mhaquila from comment #12) > As I said you, on a screen size of 1600x800 with the version 4.7.2 IT DIDN'T > FUNCTION CORRECTLY: the screen shots are taken with this version… Because, > as I yet said, the column width depends of the screen size. > You also said, in comment #8 "My version for Linux is the 4.6.4 ...", and the screenshots were provided in comment #5 and #6, so prior to your saying you were on 4.6.4. I can only repeat that 4.7.2 works correctly for me. If it doesn't for you, I would look to your distro/whatever. I cannot help with a Windows problem as I gave up on that some years ago. I believe there have been build problems with the Widows version, but I understand that that issue is now resolved, but probably not yet distributed. > And I don't know at all what you put the bug resolved when it's not! -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 allan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version Fixed In||4.7.x Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #11 from allan --- > 4.6.4 is now very old and you are missing a lot of bug fixes and > improvements, particularly in KMM. I would strongly advise getting the > latest release from the Claydoh ppa. If you want to use KMM on Linux, then will you upgrade? No development work will occur if the problem has already been fixed. I have just installed 4.7.2 again and checked this. All columns are fully displayed. On a wide screen, the Details column expands, but the other columns are still displayed correctly. An empty Number field starts off narrow, but expands to show the data in full. I don't think I can say more. -- You are receiving this mail because: You are the assignee for the bug.
Re: unexpected presence of a payee in an investment transaction
I'm not sure I understand so excuse me if I've got it wrong.You have a payee you want to delete but can't see how? Why, what happens when you try? Do you have any matching set'? Allan Sent from my Samsung device Original message From: Jack Date: 14/06/2016 23:07 (GMT+00:00) To: kmymoney-devel@kde.org Subject: Re: unexpected presence of a payee in an investment transaction On 2016.06.14 17:36, aga wrote: > On 14/06/16 20:59, Jack wrote: >> I was tracking down a recent payment, and so was looking at the Payee >> Veiw for a payee "MetLife". Most of the transactions are plain >> checks. >> However, there was one investment transaction. It was for purchase >> of a >> security "METLIFE INC COM" with the funds coming from the default >> brokerage account for that investment account. Nowhere in the >> ledger do >> I see any mention of the Payee MetLife. (Yes, it's the same company >> - I >> own shares in it, and pay it for insurance premiums - completely >> unrelated activities.) I have not yet dug into the actual KMY file, >> but >> I'm really curious why there is any payee involved in a "buy shares" >> transaction with no fees involved. I believe all the relevant >> transactions were imported by OFX, either direct connect or file >> import >> (libofx, not aqbanking). >> >> Any explanations? > Was it a recent transaction? There was a time when a payee was > required, but that was removed by popular request. I actually found several more from 2014, but this one was just from this April. However, if it matched to the older ones, I can see it would continue to use the same payee as the older transactions. What I still find odd is that I don't see any way in the standard interface to remove it. Will I have to manually edit the kmy file?
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #9 from allan --- (In reply to mhaquila from comment #8) > My version for Linux is the 4.6.4 (KDE 4.14.2) and for Windows is the 4.7.2 > (KDE 4.12.5). 4.6.4 is now very old and you are missing a lot of bug fixes and improvements, particularly in KMM. I would strongly advise getting the latest release from the Claydoh ppa. Hopefully you don't see exactly the same behaviour on the Windows version? > No, it's just the problem: adding extra characters into one narrow column > don't increase the column width which is fixed I think in percent of the > screen size independently of the window size. I'm pretty certain this is not the case in the latest versions. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #7 from allan --- I don't recollect seeing that sort of behaviour recently. You didn't say what revision of KMM you use? It's some while since I dabbled in this area. Again looking for a work-around, if you add extra characters into one of your narrow columns, does that increase the column width? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #3 from allan --- (In reply to mhaquila from comment #2) > (In reply to allan from comment #1) > > Did you try widening the KMyMoney window? > > Yes, I did. However for an easy use of the program, the window can't be > widened more than the screen size, so resize the column seems to be > essential. I assume you know that you can reposition the KMM window to allow stretching to the right? I'm not suggesting that this is a satisfactory solution, but may be a possible work-around. I did actually implement a change to allow column widening, but the current method was preferred by the developers. Just so we have the complete picture, would you give - The KMM version you are using - Your screen size - Whether repositioning is helpful. Perhaps you could attach a screen-shot? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #1 from allan --- Did you try widening the KMyMoney window? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #23 from allan --- It looks to me that https://bugs.kde.org/show_bug.cgi?id=303026 still shows its problem. See comment #18. A new manually created copy of its sell transaction still objects if a fee of 12.95 is entered. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349033] option to invert transaction amounts during import
https://bugs.kde.org/show_bug.cgi?id=349033 --- Comment #3 from allan --- Pending a proper solution, it might save a little effort when importing to select the present amount column as Debit, and some other column as Credit. Then, when importing, you are given the option to accept either the debit or credit column amount, for each transaction. That's a bit of a fag, but it might be easier. The credit amount would need to be edited after import. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 128061: Fix precision of split value
> On June 2, 2016, 1 p.m., Allan Anderson wrote: > > This is not a good area for me, and takes me out of my comfort zone. > > However, I've been having a look at this, and there are one or two points, > > which may or may not be relevant. > > Firstly, the file attached to https://bugs.kde.org/show_bug.cgi?id=303026 > > does illustrate the problem. > > Secondly, the sell transaction shows a missing assignment of "ACME 0.005". > > Next, I edited it to remove the fee split, to simplify things a bit. It > > still shows the missing assignment. > > Looking now at the void MyMoneyFile::fixSplitPrecision(MyMoneyTransaction& > > t) const routine, and specifically at the last line, > > "(*its).setValue((*its).value().convertDenominator(fraction).canonicalize());" > > For the first split, I get "16180.52", but with the canonicalize() > > removed, I get "16180.525000". > > The second split gives "-16180.525000". > > Whether or not this is relevant, I really don't know and an expert opinion > > is needed, I think. I think perhaps I should have mentioned that with MyMoneyFile::fixSplitPrecision() bypassed, this file imports correctly, and the same details may be entered manually with no error. Also, I've just noticed that even where the transaction now shows no error, the consistency check reports that it has fixed the error. This it does with "if (t.splitSum().isZero()) { s.setShares(s.value()); }" Using similar code in MyMoneyFile::fixSplitPrecision() appears to resolve the problem in this bug. - Allan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128061/#review96155 --- On May 30, 2016, 6:10 p.m., Thomas Baumgart wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128061/ > --- > > (Updated May 30, 2016, 6:10 p.m.) > > > Review request for KMymoney. > > > Bugs: 345655 > http://bugs.kde.org/show_bug.cgi?id=345655 > > > Repository: kmymoney > > > Description > --- > > The problem described in bug 345655 is caused by a fraction of the splits > value that is larger than the fraction of the accounts currency. This leads > to the effect, that values are displayed with correct value but the > underlying value used for calculations is not equal to the amount displayed. > This will end up in KMyMoney presenting the user strange messages like > 'Unassigned value of 0.00' which do not make sense. The difference is in > reality between 0 and 0.01, e.g. 0.008. > > The attached patch resolves this problem by rounding the numbers to the > correct fraction of the referrenced account. > > > Diffs > - > > kmymoney/mymoney/mymoneyfile.h 0fd558b > kmymoney/mymoney/mymoneyfile.cpp 568675c > kmymoney/mymoney/mymoneyfiletest.h 657ed39 > kmymoney/mymoney/mymoneyfiletest.cpp 810b15f > > Diff: https://git.reviewboard.kde.org/r/128061/diff/ > > > Testing > --- > > Test case is part of the patch. It uses the values provided in the sample > attached to the bug 345655 entry. > > > Thanks, > > Thomas Baumgart > >
Re: Review Request 128061: Fix precision of split value
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128061/#review96155 --- This is not a good area for me, and takes me out of my comfort zone. However, I've been having a look at this, and there are one or two points, which may or may not be relevant. Firstly, the file attached to https://bugs.kde.org/show_bug.cgi?id=303026 does illustrate the problem. Secondly, the sell transaction shows a missing assignment of "ACME 0.005". Next, I edited it to remove the fee split, to simplify things a bit. It still shows the missing assignment. Looking now at the void MyMoneyFile::fixSplitPrecision(MyMoneyTransaction& t) const routine, and specifically at the last line, "(*its).setValue((*its).value().convertDenominator(fraction).canonicalize());" For the first split, I get "16180.52", but with the canonicalize() removed, I get "16180.525000". The second split gives "-16180.525000". Whether or not this is relevant, I really don't know and an expert opinion is needed, I think. - Allan Anderson On May 30, 2016, 6:10 p.m., Thomas Baumgart wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128061/ > --- > > (Updated May 30, 2016, 6:10 p.m.) > > > Review request for KMymoney. > > > Bugs: 345655 > http://bugs.kde.org/show_bug.cgi?id=345655 > > > Repository: kmymoney > > > Description > --- > > The problem described in bug 345655 is caused by a fraction of the splits > value that is larger than the fraction of the accounts currency. This leads > to the effect, that values are displayed with correct value but the > underlying value used for calculations is not equal to the amount displayed. > This will end up in KMyMoney presenting the user strange messages like > 'Unassigned value of 0.00' which do not make sense. The difference is in > reality between 0 and 0.01, e.g. 0.008. > > The attached patch resolves this problem by rounding the numbers to the > correct fraction of the referrenced account. > > > Diffs > - > > kmymoney/mymoney/mymoneyfile.h 0fd558b > kmymoney/mymoney/mymoneyfile.cpp 568675c > kmymoney/mymoney/mymoneyfiletest.h 657ed39 > kmymoney/mymoney/mymoneyfiletest.cpp 810b15f > > Diff: https://git.reviewboard.kde.org/r/128061/diff/ > > > Testing > --- > > Test case is part of the patch. It uses the values provided in the sample > attached to the bug 345655 entry. > > > Thanks, > > Thomas Baumgart > >
Re: Review Request 128061: Fix precision of split value
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128061/#review96153 --- >From the list - https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #18 from allan --- Referring back to comments #3, #4, #5, and https://bugs.kde.org/show_bug.cgi?id=303026, does that issue now need revisiting? --- Comment #19 from Thomas Baumgart --- Allan, good point. The modification is almost identical, though it differs a bit. The rounding problem caught in https://bugs.kde.org/show_bug.cgi?id=303026 could still happen. Can you please comment on reviewboard so that we can think of how to deal with the situation? It would be nice if you can provide me with a testcase (probably just different values) that fails. - Allan Anderson On May 30, 2016, 6:10 p.m., Thomas Baumgart wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128061/ > --- > > (Updated May 30, 2016, 6:10 p.m.) > > > Review request for KMymoney. > > > Bugs: 345655 > http://bugs.kde.org/show_bug.cgi?id=345655 > > > Repository: kmymoney > > > Description > --- > > The problem described in bug 345655 is caused by a fraction of the splits > value that is larger than the fraction of the accounts currency. This leads > to the effect, that values are displayed with correct value but the > underlying value used for calculations is not equal to the amount displayed. > This will end up in KMyMoney presenting the user strange messages like > 'Unassigned value of 0.00' which do not make sense. The difference is in > reality between 0 and 0.01, e.g. 0.008. > > The attached patch resolves this problem by rounding the numbers to the > correct fraction of the referrenced account. > > > Diffs > - > > kmymoney/mymoney/mymoneyfile.h 0fd558b > kmymoney/mymoney/mymoneyfile.cpp 568675c > kmymoney/mymoney/mymoneyfiletest.h 657ed39 > kmymoney/mymoney/mymoneyfiletest.cpp 810b15f > > Diff: https://git.reviewboard.kde.org/r/128061/diff/ > > > Testing > --- > > Test case is part of the patch. It uses the values provided in the sample > attached to the bug 345655 entry. > > > Thanks, > > Thomas Baumgart > >
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #18 from allan --- Referring back to comments #3, #4, #5, and https://bugs.kde.org/show_bug.cgi?id=303026, does that issue now need revisiting? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #10 from allan --- (In reply to Jack from comment #9) > As I understand it, all current developer time is going to the conversion to > KDE Frameworks. This issue is unlikely to be addressed until after that is > complete. > > In addition, while this may certainly be annoying, if does not make KMM > useless. I track several investment accounts in KMM, with multiple brokers, > and it works just fine for me. Remember, nobody is being paid to work on > KMM. > (You may also want to be careful about your choice of words, as "sued" > has a particular legal implication in English, definitely in the US.) I took that to be a typo for 'used'. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874 --- Comment #12 from allan --- (In reply to Jeff from comment #9) > That line: > > tr.m_amount = -amount; > > is the one I changed in my patch to fix my problem for "sells". Need remove > the negative sign. Sorry, but I'm a bit puzzled here. With your suggested change, to remove the sign reversal, when the transaction imports, the result shows as a deposit of $8.77 (positive). Throughout the import, the negative sign is maintained, as far as I can see. So, I don't see "The cash account should decrease by 8.77." Why don't I see the result you are expecting? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874 --- Comment #8 from allan --- (In reply to Jeff from comment #6) > Hi Łukasz, > > There is still a problem with the QIF import with your change. My test file > also tested the case where the commission was greater than the proceeds from > the sale (which can happen when trading options.) Your fix changed a "sell" > trade that actually cost money into one that brought in money. The example > in my test file was the "sell" of the "NFLX Aug 18 2012 110.0 Call". The > price is 0.02, times 100 shares = 2.00. The commission is 10.77. So income > of 2.00, outgo of 10.77 makes the total -8.77 (as shown in the U and T > values in the QIF file). The cash account should decrease by 8.77. Your > change turned that into a positive 8.77, and increased the cash account. > This is admittedly a corner case, and I think I am the only KMM user that > trades options because I have made a bunch of other changes to the KMM code > to support that. > It would not have surprised me if your problem was caused by the same issue I reported in https://bugs.kde.org/show_bug.cgi?id=362139 comment #7, with the negative sign getting dropped. However, the sign appears to be negative throughout the import process until - Line 1564 in mymoneyqifreader.cpp() "else if (action == "sell") { d->st.m_listPrices += price; tr.m_shares = -quantity; tr.m_amount = -amount; tr.m_eAction = (MyMoneyStatement::Transaction::eaSell);" I don't profess to know anything about a sell where the commission is greater than the proceeds of the sale. However, I think what happens in general is that a sell is expected to be input with no sign, and therefore the amount needs to be set to a negative value. So, in your case, as you have a negative sign on input, that sign gets removed. That seems to imply that the commission needs to negative in your case, and reversing the signs appears to produce your expected result. If this is all rubbish, just ignore it. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #10 from allan --- (In reply to NSLW from comment #9) > (In reply to allan from comment #7) > > I think I've traced it, possibly, to the recent fee patch. > > In investprocessing.cpp(), at circa line 1723 - > > tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); > > appears to drop the sign. > > I'm glad you did it and gave feedback. I apologize if something is broken > for you lately with CSV imports. I don't have any problem, as I was using a test file, not live data. > I would like to help fixing that. Could you > send your problematic, anonymized CSV test file and explain me what result > you expect after importing? > As I understand, you've got two CashDividends: one negative and one > positive. Frankly I don't get it, shouldn't CashDividends be always > positive, as it its you who gets the cash? The test file is one I've used for several years, and originally I obtained it from another user. At that time, I was developing the CSV investment handling and I found the file quite useful, as the data was not the usual straight-forward simple investment transactions. I cannot now remember if the CashDividend with the negative amount was an original entry, or whether I modified it for the purpose. My "justification/rationale" for the entry was that it was documenting a refund of an erroneous earlier transaction. I suppose a "miscexp" would be similar (or perhaps not). The file was from a US broker, who did produce some odd methods in his files. As it's quite small, here it is below. "Trade Date","Settlement Date","Type","Description 1 ","Description 2","Symbol/CUSIP","Quantity","Price ($)","Amount ($)" "","2/24/2010","DividendAndInterest","Div","description","NECZX","","","504.72" "","3/28/2010","Other","Div","description",""NECZX"","","","-504.72" -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...
https://bugs.kde.org/show_bug.cgi?id=361021 --- Comment #14 from allan --- Just to note that I discovered a possible problem with this, and documented it, in error, in https://bugs.kde.org/show_bug.cgi?id=362139, comment #7. See there for follow up. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874 --- Comment #7 from allan --- (In reply to NSLW from comment #4) > Statement reader did it wrong also for CSV imports (see bug #361021) so I > made corrections to the code which seemed to help also QIF reader. Honestly > at that time I didn't know that investment statements are imported by > anything else than CSV and thanks to your bug and code review I see bigger > picture now. I proposed two next patches to statement reader which now I > must review myself because I already see mixed logic between QIF and CSV > imports, which somehow worked by now. > It would be nice if you could send me for testing an anonymized QIF file > with less frequent transaction types such as "dividends" etc. > > I don't know about OFX imports because valid ACCTTYPEs are only: CHECKING, > SAVINGS, MONEYMRKT, and CREDITLINE, and there are no investment ACCTTYPE, so > I assume OFX doesn't support that. Correct me if I'm wrong. The OFX specification 2.0.3 includes - "CHAPTER 13 INVESTMENTS OFX supports download of security information and detailed investment account statements including transactions, open orders, balances, and positions. " plus a lot more in detail. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #8 from allan --- (In reply to allan from comment #7) > Today, and the first for a while, I updated from HEAD and to ensure all was > OK, I did a CSV import of an investment file, which contained two similar > entries. They were both CashDividends, with the main difference being that > one had an identical but negative amount. On import, the negative sign had > been dropped. > I think I've traced it, possibly, to the recent fee patch. > In investprocessing.cpp(), at circa line 1723 - > tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); > appears to drop the sign. This comment of mine, #7, was added to this bug when I first discovered this problem, but on investigating, it seems that it doesn't really belong here, but probably to BUG: 361021. I can add this entry to that bug report, but that might cause confusion about which bug to follow. So, do I leave as is? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #7 from allan --- Today, and the first for a while, I updated from HEAD and to ensure all was OK, I did a CSV import of an investment file, which contained two similar entries. They were both CashDividends, with the main difference being that one had an identical but negative amount. On import, the negative sign had been dropped. I think I've traced it, possibly, to the recent fee patch. In investprocessing.cpp(), at circa line 1723 - tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); appears to drop the sign. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362430] KMyMoney crashed on account type change
https://bugs.kde.org/show_bug.cgi?id=362430 --- Comment #1 from allan --- I am able to do this, and then revert it, with no problem, using the development branch. 4.6.6 is now pretty old, and I would advise that you might be better off getting 4.7.2, possibly from the Claydoh PPA. Was this an isolated event, or were you able to reproduce the problem? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362399] Import of payees details
https://bugs.kde.org/show_bug.cgi?id=362399 --- Comment #1 from allan --- (In reply to Martin Tlustos from comment #0) > I would like to import my payees details into kmymoney. Manually adding the > information for several hundred payees is too cumbersome. > > Reproducible: Always Yes, I can imagine that that would be a bit boring. >From where do you intend to import (which app)? It's a long time since I used Quicken, but if it is relevant, try this - from a Google search 'In Q2012: File > File Export > QIF File. Choose a File to export to. In the "Include in Export" section, uncheck all but "Category List" and "Memorized Payees" then In Q2013: File > File Import > QIF File. Browse to the QIF file created in Q2012. Choose any account (or All Accounts) to import into. In the "Include in import" section, uncheck all but "Category List" and "Memorized Payees". ' - to confirm that you can actually export them. If that works, try to do a QIF import to KMyMoney. If that is unsuccessful, could you attach the file to this bug report, or send off-line to me. Include the categories - they might be useful for comparison. I have, a long time ago, imported a category list, but am not sure about payees. Allan -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 127712: Bug 360747 CSV Importer detects more columns than are assigned
> On April 27, 2016, 7:11 p.m., Cristian Oneț wrote: > > kmymoney/plugins/csvimport/investprocessing.cpp, line 858 > > <https://git.reviewboard.kde.org/r/127712/diff/1/?file=456462#file456462line858> > > > > Is this local variable really necessary? I had noticed this. Whilst it is used, I suspect that it could be replaced by m_parse, with possible minor adjustment, but I can't test, I'm afraid. - Allan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127712/#review94911 --- On April 22, 2016, 6:56 p.m., Łukasz Wojniłowicz wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127712/ > --- > > (Updated April 22, 2016, 6:56 p.m.) > > > Review request for KMymoney. > > > Bugs: 360747 > http://bugs.kde.org/show_bug.cgi?id=360747 > > > Repository: kmymoney > > > Description > --- > > Fixes bug #360747. Current routine doesn't calculate columns well when > FieldDelimiter=DecimalSymbol. parseLine() from csvutil.cpp does it > properly. > > > Diffs > - > > kmymoney/plugins/csvimport/investprocessing.cpp 73e4e4d > > Diff: https://git.reviewboard.kde.org/r/127712/diff/ > > > Testing > --- > > 1) CSV file where FieldDelimiter=DecimalSymbol=comma (Test file from bug > #360747) > 2) CSV file where FieldDelimiter=comma and DecimalSymbol=dot > > > Thanks, > > Łukasz Wojniłowicz > >
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #17 from allan --- (In reply to NSLW from comment #16) > (In reply to allan from comment #15) > > Unfortunately, I am unable to follow the detail of the latest proposed > > patch, but I would like to urge some caution. It may be that the proposal > > does not affect the config file - csvimporterrc, but in its current > > implementation, it is possible for the user to edit the entries in the file > > to suit his needs. If instead the entries are moved into the coding, then > > recompilation would be required for any changes, which most users would not > > wish to face. If this is not the case, then that's fine. > > The second version of the patch is different from the first you've committed > only in asking m_map for security name using its symbol in uppercase instead > of lowercase, because m_map is from now on filled by default with symbols in > uppercase and m_map won't return correct name if asked in lowercase. > > AFAIK no part of csvimporterrc shouldn't impact the behavior changed here. > In fact we make the behavior lax, so user can in any time change his symbol > from uppercase to lowercase or mixed case and still get it detected as the > same symbol. > > If that's fine I think I can apply second version of patch just like you've > applied the first one. That sounds good to me. Would you check on the Frameworks side please, as Christian committed only my 'partial' patch. -- You are receiving this mail because: You are the assignee for the bug.
Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty
> On April 7, 2016, 7:59 p.m., Christian David wrote: > > kmymoney/plugins/csvimport/investprocessing.cpp, line 1967 > > <https://git.reviewboard.kde.org/r/127559/diff/1/?file=455181#file455181line1967> > > > > Should become > > ```m_shrsinList = profilesGroup.readEntry("ShrsinParam", > > m_shrsinList);``` > > > > The if() is very long and not needed here. However, I still do not know > > if this is the issue. Also the ```i18nc()s``` from ```init()``` could go > > here if the readSettings method is always called, which I do not know > > either. > > Allan Anderson wrote: > > Should become > > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList); > > I'm not sure I understand this. The second parameter is the default > value to return if the key is not found. What does it achieve in this case? > > > The if() is very long and not needed here. > > There are several ifs around here, but I don't see an unduly long one. > > > Also the i18nc()s from init() > > could go here if the readSettings method is always called, which I do > not know either. > > readSettings is called only once, from void > InvestProcessing::slotFileDialogClicked(), so that code could be moved > somewhere in void InvestProcessing::readSettings(), I think. > > Łukasz Wojniłowicz wrote: > > Should become > > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList); > > I compiled KMyMoney code according to your change for every m_XXXList > variable and ran my test case. Proposed line looks neat but doesn't work for > me. SellParam= etc. are empty in my csvimporterrc after just created new > profile. > > >readSettings is called only once, from void > InvestProcessing::slotFileDialogClicked(), so that code could be moved > somewhere in void InvestProcessing::readSettings(), I think. > > Please give a code and I'll test it. > > > I do not know the full conversation but I am pretty sure this patch > will not solve the issue. If something in the newly created rc file is > missing, the write method seems to fail, not the read method. > > My loose observation: Write method is called at the end of importing and > read method is called after creating new importing profile for investment. > > Christian David wrote: > > I do not know the full conversation but I am pretty sure this patch > will not solve the issue. If something in the newly created rc file is > missing, the write method seems to fail, not the read method. > > I withdrew this idea. You should not waste your time with it. > > > I compiled KMyMoney code according to your change for every m_XXXList > variable and ran my test case. Proposed line looks neat but doesn't work for > me. SellParam= etc. are empty in my csvimporterrc after just created new > profile. > > You are right. The code recomended by me has a different behaviour. > However, now I doubt that anything I wrote was actually helpfull. I just > briefly inspected the code – now I see that is more complex than I thougt. So > my recomendations are based on insufficent knowledge. Due to the description > in the bug report I still think there is a high chance that the issue is in > the write function. > > Łukasz Wojniłowicz wrote: > Due to the description in the bug report I still think there is a high > chance that the issue is in the write function. > > > And you may be right, look what I've found. > New entry of importing profile in `$HOME/.kde/share/config/csvimporterrc` > is created in csvdialog.cpp by following routine > > ```c++ > void CSVDialog::createProfile(QString newName) > { > KSharedConfigPtr config = > KSharedConfig::openConfig(KStandardDirs::locateLocal("config", > "csvimporterrc")); > KConfigGroup bankProfilesGroup(config, "BankProfiles"); > > bankProfilesGroup.writeEntry("BankNames", m_profileList); > bankProfilesGroup.config()->sync(); > > KConfigGroup bankGroup(config, "BankProfiles"); > QString txt = "Profiles-" + newName; > > KConfigGroup profilesGroup(config, "Profiles-New Profile###"); > > KSharedConfigPtr configBackup = > KSharedConfig::openConfig(KStandardDirs::locate("config", "csvimporterrc")); > KConfigGroup bkprofilesGroup(configBackup, &
Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty
> On April 7, 2016, 7:59 p.m., Christian David wrote: > > kmymoney/plugins/csvimport/investprocessing.cpp, line 1967 > > <https://git.reviewboard.kde.org/r/127559/diff/1/?file=455181#file455181line1967> > > > > Should become > > ```m_shrsinList = profilesGroup.readEntry("ShrsinParam", > > m_shrsinList);``` > > > > The if() is very long and not needed here. However, I still do not know > > if this is the issue. Also the ```i18nc()s``` from ```init()``` could go > > here if the readSettings method is always called, which I do not know > > either. > > Allan Anderson wrote: > > Should become > > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList); > > I'm not sure I understand this. The second parameter is the default > value to return if the key is not found. What does it achieve in this case? > > > The if() is very long and not needed here. > > There are several ifs around here, but I don't see an unduly long one. > > > Also the i18nc()s from init() > > could go here if the readSettings method is always called, which I do > not know either. > > readSettings is called only once, from void > InvestProcessing::slotFileDialogClicked(), so that code could be moved > somewhere in void InvestProcessing::readSettings(), I think. > > Łukasz Wojniłowicz wrote: > > Should become > > m_shrsinList = profilesGroup.readEntry("ShrsinParam", m_shrsinList); > > I compiled KMyMoney code according to your change for every m_XXXList > variable and ran my test case. Proposed line looks neat but doesn't work for > me. SellParam= etc. are empty in my csvimporterrc after just created new > profile. > > >readSettings is called only once, from void > InvestProcessing::slotFileDialogClicked(), so that code could be moved > somewhere in void InvestProcessing::readSettings(), I think. > > Please give a code and I'll test it. > > > I do not know the full conversation but I am pretty sure this patch > will not solve the issue. If something in the newly created rc file is > missing, the write method seems to fail, not the read method. > > My loose observation: Write method is called at the end of importing and > read method is called after creating new importing profile for investment. > > Christian David wrote: > > I do not know the full conversation but I am pretty sure this patch > will not solve the issue. If something in the newly created rc file is > missing, the write method seems to fail, not the read method. > > I withdrew this idea. You should not waste your time with it. > > > I compiled KMyMoney code according to your change for every m_XXXList > variable and ran my test case. Proposed line looks neat but doesn't work for > me. SellParam= etc. are empty in my csvimporterrc after just created new > profile. > > You are right. The code recomended by me has a different behaviour. > However, now I doubt that anything I wrote was actually helpfull. I just > briefly inspected the code – now I see that is more complex than I thougt. So > my recomendations are based on insufficent knowledge. Due to the description > in the bug report I still think there is a high chance that the issue is in > the write function. > > Łukasz Wojniłowicz wrote: > Due to the description in the bug report I still think there is a high > chance that the issue is in the write function. > > > And you may be right, look what I've found. > New entry of importing profile in `$HOME/.kde/share/config/csvimporterrc` > is created in csvdialog.cpp by following routine > > ```c++ > void CSVDialog::createProfile(QString newName) > { > KSharedConfigPtr config = > KSharedConfig::openConfig(KStandardDirs::locateLocal("config", > "csvimporterrc")); > KConfigGroup bankProfilesGroup(config, "BankProfiles"); > > bankProfilesGroup.writeEntry("BankNames", m_profileList); > bankProfilesGroup.config()->sync(); > > KConfigGroup bankGroup(config, "BankProfiles"); > QString txt = "Profiles-" + newName; > > KConfigGroup profilesGroup(config, "Profiles-New Profile###"); > > KSharedConfigPtr configBackup = > KSharedConfig::openConfig(KStandardDirs::locate("config", "csvimporterrc")); > KConfigGroup bkprofilesGroup(configBackup, &
[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)
https://bugs.kde.org/show_bug.cgi?id=361865 --- Comment #5 from allan --- Many/most/some users migrate from Quicken to KMM. The English terms in question are exactly the same as those used in Quicken, and probably the MS equivalent too. My advice is "Leave well alone." -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)
https://bugs.kde.org/show_bug.cgi?id=361865 --- Comment #3 from allan --- I would not waste my time looking into changing the term 'share' here. It is embedded deeply within KMyMoney source code, and appears well over 900 times. Bond appears 13 times. I agree with Jack that possibly instead what is needed is additional guidance to the translators. Out of interest, what is the distinction between the original term and the proposed revision? -- You are receiving this mail because: You are the assignee for the bug.