[kmymoney4] [Bug 376010] Import CSV with leading column empty crashes KMyMoney

[allan]

https://bugs.kde.org/show_bug.cgi?id=376010

--- Comment #3 from allan <agande...@gmail.com> ---
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 <bugzilla_nore...@kde.org> 
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 <wdd5...@gmail.com> ---
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 <bugzilla_nore...@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=376010
>
> --- Comment #1 from allan <agande...@gmail.com> ---
> 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

[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 <bugzilla_nore...@kde.org> 
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 <wdd5...@gmail.com> ---
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 <bugzilla_nore...@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=376010
>
> --- Comment #1 from allan <agande...@gmail.com> ---
> 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

[allan]

https://bugs.kde.org/show_bug.cgi?id=376010

--- Comment #1 from allan <agande...@gmail.com> ---
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

[Allan Anderson]

---
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 372166] CSV import not allowing choice of account for import on KF5.

[allan]

https://bugs.kde.org/show_bug.cgi?id=372166

--- Comment #2 from allan <agande...@gmail.com> ---
(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 374352] Payee merge converts imported name containing string "Check" to existing Payee name "Check"

[allan]

https://bugs.kde.org/show_bug.cgi?id=374352

--- Comment #4 from allan <agande...@gmail.com> ---
(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"

[allan]

https://bugs.kde.org/show_bug.cgi?id=374352

--- Comment #2 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

allan <agande...@gmail.com> 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

[allan]

https://bugs.kde.org/show_bug.cgi?id=374082

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from allan <agande...@gmail.com> ---
>> --- Comment #3 from Lenka Filova <lenka_fil...@yahoo.com> ---
>> 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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

--- Comment #15 from allan <agande...@gmail.com> ---
*** 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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

--- Comment #14 from allan <agande...@gmail.com> ---
--- Comment #13 from Lenka Filova <lenka_fil...@yahoo.com> ---
>> 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

[Allan Anderson]

---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=372547

--- Comment #4 from allan <agande...@gmail.com> ---
(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

[allan]

https://bugs.kde.org/show_bug.cgi?id=374082

--- Comment #1 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

--- Comment #12 from allan <agande...@gmail.com> ---
(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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

--- Comment #11 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=342196

--- Comment #10 from allan <agande...@gmail.com> ---
(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ț <onet.crist...@gmail.com> ---
> > 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

[allan]

https://bugs.kde.org/show_bug.cgi?id=349938

--- Comment #24 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=349938

--- Comment #22 from allan <agande...@gmail.com> ---
(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

[allan]

https://bugs.kde.org/show_bug.cgi?id=349938

--- Comment #19 from allan <agande...@gmail.com> ---
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.

[kmymoney4] [Bug 372254] Crash when importing CSV file

[allan]

https://bugs.kde.org/show_bug.cgi?id=372254

--- Comment #4 from allan <agande...@gmail.com> ---
(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

[allan]

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

[allan]

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

[allan]

https://bugs.kde.org/show_bug.cgi?id=372547

--- Comment #2 from allan <agande...@gmail.com> ---
@ 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 372507] QIF importer fails to list all accounts

[allan]

https://bugs.kde.org/show_bug.cgi?id=372507

allan <agande...@gmail.com> changed:

   What|Removed |Added

  Component|onlinebanking   |general

--- Comment #2 from allan <agande...@gmail.com> ---
Online banking is something else again.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 372254] Crash when importing CSV file

[allan]

https://bugs.kde.org/show_bug.cgi?id=372254

--- Comment #3 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=372254

--- Comment #2 from allan <agande...@gmail.com> ---
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

[allan]

https://bugs.kde.org/show_bug.cgi?id=372254

--- Comment #1 from allan <agande...@gmail.com> ---
(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

[allan]

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] New: CSV Import account selector malfunction on KF5

[allan]

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

[allan]

https://bugs.kde.org/show_bug.cgi?id=372163

--- Comment #2 from allan <agande...@gmail.com> ---
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.

[allan]

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

[allan]

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

[allan]

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ț <onet.crist...@gmail.com> 
Date: 25/10/2016  19:08  (GMT+00:00) 
To: For KMyMoney development <kmymoney-devel@kde.org> 
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 <agande...@gmail.com>:
> 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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=371069

--- Comment #1 from allan <agande...@gmail.com> ---
Created attachment 101617
  --> https://bugs.kde.org/attachment.cgi?id=101617=edit
UTF-16 file

-- 
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...."

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368593

--- Comment #7 from allan <agande...@gmail.com> ---
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

[Allan Anderson]

> 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

[Allan Anderson]

> 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

[Allan Anderson]

---
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)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=272398

--- Comment #8 from allan <agande...@gmail.com> ---
(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)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=272398

--- Comment #6 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362373

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |UNCONFIRMED

--- Comment #2 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #32 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #30 from allan <agande...@gmail.com> ---
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

[Allan Anderson]

> 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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #28 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #27 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364425

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365802

--- Comment #1 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365307

--- Comment #4 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365307

--- Comment #2 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=365023

--- Comment #1 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #24 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364311

--- Comment #14 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364311

allan <agande...@gmail.com> 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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364311

--- Comment #11 from allan <agande...@gmail.com> ---
> 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.

[kmymoney4] [Bug 364311] Ledgers columns can't be resized

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364311

--- Comment #3 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=364311

--- Comment #1 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #23 from allan <agande...@gmail.com> ---
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.

Re: Review Request 128061: Fix precision of split value

[Allan Anderson]

> 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

[Allan Anderson]

---
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

[Allan Anderson]

---
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 <agande...@gmail.com> ---
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 <tbaumg...@kde.org> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #18 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=345655

--- Comment #10 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #12 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #8 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362139

--- Comment #10 from allan <agande...@gmail.com> ---
(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...

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361021

--- Comment #14 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351874

--- Comment #7 from allan <agande...@gmail.com> ---
(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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362139

--- Comment #8 from allan <agande...@gmail.com> ---
(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 362430] KMyMoney crashed on account type change

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362430

--- Comment #1 from allan <agande...@gmail.com> ---
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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=362399

--- Comment #1 from allan <agande...@gmail.com> ---
(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

[Allan Anderson]

> 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

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #17 from allan <agande...@gmail.com> ---
(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

[Allan Anderson]

> 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, "Profiles

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Allan Anderson]

> 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, "Profiles

[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361865

--- Comment #5 from allan <agande...@gmail.com> ---
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)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361865

--- Comment #3 from allan <agande...@gmail.com> ---
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.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #15 from allan <agande...@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #14 from allan <agande...@gmail.com> ---
Very sadly, I find I can not continue my involvement.  Thomas is aware of the
situation.

I think it might be as well for this complete topic to be submitted to
Reviewboard.

Allan

-- 
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

[Allan Anderson]

> 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.

> 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.


- Allan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94397
---


On April 3, 2016, 4:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 4:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Allan Anderson]

> On April 3, 2016, 12:37 p.m., Allan Anderson wrote:
> >
> 
> Allan Anderson wrote:
> We have had discussons about this in the bug report.  I think you are 
> confusing the issue by stating your experience (using the Polish translation) 
> as a general issue.  For me, if I delete the csvimporterrc file and then 
> initiate loading of an investment CSV, a new rc file is created containing 
> default values for all investment types. 
> From the extract of your rc file in the bug report, several investment 
> types have empty fields, although the Buy has an entry.
> 
> Łukasz Wojniłowicz wrote:
> For me, if I delete the csvimporterrc file and then initiate loading of 
> an investment CSV, a new rc file is created containing default value only for 
> Buy and Reinvest Dividend entry.
> I don't understand the confusion you're talking; this patch helps me. Do 
> you say it's wrong?

Just to let you know I'm still here.  Have had major system problems, that I'm 
still recovering from.


- Allan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94211
---


On April 3, 2016, 4:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 4:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Allan Anderson]

> On April 3, 2016, 12:37 p.m., Allan Anderson wrote:
> >

We have had discussons about this in the bug report.  I think you are confusing 
the issue by stating your experience (using the Polish translation) as a 
general issue.  For me, if I delete the csvimporterrc file and then initiate 
loading of an investment CSV, a new rc file is created containing default 
values for all investment types. 
>From the extract of your rc file in the bug report, several investment types 
>have empty fields, although the Buy has an entry.


- Allan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94211
---


On April 3, 2016, 4:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 4:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

Re: Review Request 127559: BUG 360129 Do not fetch from csvimporterrc if it's empty

[Allan Anderson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127559/#review94211
---



- Allan Anderson


On April 3, 2016, 4:45 a.m., Łukasz Wojniłowicz wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127559/
> ---
> 
> (Updated April 3, 2016, 4:45 a.m.)
> 
> 
> Review request for KMymoney.
> 
> 
> Bugs: 360129
> http://bugs.kde.org/show_bug.cgi?id=360129
> 
> 
> Repository: kmymoney
> 
> 
> Description
> ---
> 
> Fixes bug #360129. During creation of new investment statement
> template, transaction types are initialized in
> investprocessing.cpp, but then are overridden with empty fields
> from profile that was just created in csvimporterrc which results
> in every non-buy transaction unrecognized during the import.
> 
> 
> Diffs
> -
> 
>   kmymoney/plugins/csvimport/investprocessing.cpp 3879819 
> 
> Diff: https://git.reviewboard.kde.org/r/127559/diff/
> 
> 
> Testing
> ---
> 
> Tested using financial statement from bug #360129.
> 
> 
> Thanks,
> 
> Łukasz Wojniłowicz
> 
>

[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361271

--- Comment #5 from allan <agande...@gmail.com> ---
(In reply to Ricardo Esdra from comment #4)
> Created attachment 98194 [details]
> attachment-18641-0.html
> 
> I've auto-backup, in megasync cloud, and his update too stayed with 0 kb
> I'll use a old file what I've of february 29, and redoing it until today.
> 
> 
> How I can create a option for auto daily backup?
> exemple [file.kmy_20130401] in the name
> 
> --
> Ricardo Libanio
> 
> 
> 
> 
> 
>  Em Sex, 01 Abr 2016 17:19:30 -0300 allan via KDE Bugzilla
> bugzilla_nore...@kde.org escreveu  
> 
> https://bugs.kde.org/show_bug.cgi?id=361271 
>  
> --- Comment #3 from allan agande...@gmail.com --- 
> Just in case there's a hint of help, I don't suppose you could have setup
> for 
> auto-backup? In which case, there might be copies in the same folder as your 
> *.kmy files? 
>  
> Allan

See the KMyMoney handbook -
https://docs.kde.org/stable4/en/extragear-office/kmymoney/firsttime.backup.html.

The information is also in the application - see Help -> KMyMoney handbook ->
Using KMyMoney for the first time -> Backing up.

Plus, see Settings → Configure KMyMoney-> General -> Global -> Autosave...

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361271

--- Comment #3 from allan <agande...@gmail.com> ---
Just in case there's a hint of help, I don't suppose you could have setup for
auto-backup?  In which case, there might be copies in the same folder as your
*.kmy files?

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361191] Reconciled operations won't show up

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361191

--- Comment #1 from allan <agande...@gmail.com> ---
I would advise getting an up-to-date version, first of all.  Look for 4.7.2 in
the Claydoh PPA.

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #13 from allan <agande...@gmail.com> ---
(In reply to NSLW from comment #12)
> (In reply to allan from comment #11)
> > Are you sure about the change to csvwizard.cpp?  As far as I can see, with 
> > "exists = false;" in the while loop, it works correctly.
> 
> As long as list variable is not empty. If it's empty you wont even enter
> while loop (thus wont even define exists variable) and it is empty if you
> have no securities on "securities tab". It's corner case, I'm sure of.

Yes, of course.  You are right.

I think we're all happy with this now, so I'll be going ahead to commit.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #11 from allan <agande...@gmail.com> ---
Are you sure about the change to csvwizard.cpp?  As far as I can see, with 
"exists = false;" in the while loop, it works correctly.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361050

--- Comment #4 from allan <agande...@gmail.com> ---
(In reply to Felix Leimbach from comment #3)
> That's exactly right and is enough to crash kmymoney-4.7.2 as per the "steps
> to reproduce" above. Obviously the real file - a paypal transaction export -
> contains more rows but they are not required to reproduce.

Not for me, I'm afraid.  No crash, no matter what column I select for the date.

Did you completely remove all the remaining rows?

Early on,  I did have problems with Paypal, because of the number of columns,
but I think that should be OK now.

So, I can't go any further at the moment.

> In fact we can narrow it down further: Removing all columns starting with
> and including "Rechnungs-Nr." in the one single line does not stop kmymoney
> from crashing. Remove one more column ("Vorgangs-Nr.") and it does not crash
> anymore.
> It is not the "Vorgangs-Nr." itself though, because renaming that does not
> fix the crash. Also, removing some columns at the beginning can also fix the
> crash.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361050

--- Comment #2 from allan <agande...@gmail.com> ---
I see only a single row, of, apparently, headings, but no actual transaction
data.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361021

--- Comment #10 from allan <agande...@gmail.com> ---
(In reply to NSLW from comment #9)
> (In reply to allan from comment #8)
> > (In reply to NSLW from comment #0)
> > > Buy transactions imported by CSV importer always have missing assignment
> > 
> > It's not correct to say that they '...always have missing assignment'  it is
> > only under certain conditions.
> 
> For me it always has missing assignment during import from CSV and empty
> ledger. Do you know conditions under which it doesn't happen?

Yes.  Often, the problem is that a Buy/Sell/ReinvDiv, which involve funds
transfers, does not have the name of the relevant checking/brokerage account
provided.  During CSV import of these types, an extra dialog opens that asks
for the name of the checking/brokerage account that is to be used.  If this is
correctly entered, then the transaction is not unbalanced. In general, I do not
have a problem, over many years,  with missing assignments.

> (In reply to allan from comment #7)
> > There is also another issue, with fees sometimes getting the wrong sign,
> > which I identified in https://bugs.kde.org/show_bug.cgi?id=360129.  I think
> > the patch in this current bug may be related.
> 
> According to my research bug #360129 can be independently fixed from this
> bug and this bug can be independently fixed from bug #360129.
> Moreover through simple sign changes in my patch I can cause both operations
> to display warning about assignment and not only for sell operations.
> How do you see them correlated?

I don't see the two bugs as related, except that
https://bugs.kde.org/show_bug.cgi?id=361029 highlighted the fee sign issue. 
I'm assuming/hoping that your patch here is for that same problem.  I haven't
yet had a chance to look into it.

> Nevertheless, Allan please analyze this and another bug with patches for
> them.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361021

--- Comment #8 from allan <agande...@gmail.com> ---
(In reply to NSLW from comment #0)
> Buy transactions imported by CSV importer always have missing assignment

It's not correct to say that they '...always have missing assignment'  it is
only under certain conditions.

> (see attachment).
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. file->import csv
> 2. choose investment
> 3. create new profile
> 4. open "test file.csv" and assign columns to values (see attachment)
> 5. FieldDelimiter to comma
> 6. TextDelimiter to double quotes
> 7. DecimalSymbol to comma
> 8. ImportCSV
> 
> Actual Results:  
> In ledger:
> All buy operations have missing assignment
> On home page:
> Balance for banking and investment account are equal.
> 
> Expected Results:  
> In ledger:
> All operations should have assignment
> On home page:
> Balance for banking and investment account should be equal only in special
> cases. Correct difference in balance is shown in attachment.
> 
> To get good balance without the need of patching one has to double click
> every operation in ledger and press enter button. Upon completion column
> value will have exact same values as column from patched KMM.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361021

--- Comment #7 from allan <agande...@gmail.com> ---
(In reply to Jack from comment #5)
> Without looking at the details, I believe this is not a problem with the CSV
> importer, but with any KMM import of an investment transaction which
> requires a brokerage account for transfer of funds.

That's not exactly true.  I've just done a QIF import of a Buy transaction, as
a test, and that correctly identified the checking account to be used.

There is also another issue, with fees sometimes getting the wrong sign, which
I identified in https://bugs.kde.org/show_bug.cgi?id=360129.  I think the patch
in this current bug may be related.

>  (I have it with OFX
> import.) The issue is that when KMM imports an investment transaction, it
> does not specify the brokerage account, so the missing assignment refers to
> the amount which would go to that account.  When you edit the transaction,
> KMM automatically enters the brokerage account, so the error disappears.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 361004] CSV Importer doesn't read DecimalSymbol stored in csvimporterrc

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361004

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #5 from allan <agande...@gmail.com> ---
Well spotted!  Now, why did I do that?

I'll come back to this later.

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360938] Scheduled transactions entered in credit card (liability) have random descriptions populated

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360938

--- Comment #5 from allan <agande...@gmail.com> ---
On 26/03/16 15:55, via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=360938
>
> --- Comment #4 from lp.allar...@gmail.com ---
> I am not off to a good start.  First I downloaded the sources of 4.7.2 then
> followed the instructions of the README.cmake file which mentions that I 
> should
> run "sudo apt-get build-dep kmymoney" since I am on ubuntu (mint)..  The 
> output
> was
>
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to find a source package for kmymoney
>
> Then I tried to manually start the cmake compilation process and got :
>
> CMake Error at CMakeLists.txt:72 (find_package):
>By not providing "FindQGpgme.cmake" in CMAKE_MODULE_PATH this project has
>asked CMake to find a package configuration file provided by "QGpgme", but
>CMake did not find one.
>
>Could not find a package configuration file provided by "QGpgme" with any
>of the following names:
>
>  QGpgmeConfig.cmake
>  qgpgme-config.cmake
>
>Add the installation prefix of "QGpgme" to CMAKE_PREFIX_PATH or set
>"QGpgme_DIR" to a directory containing one of the above files.  If "QGpgme"
>provides a separate development package or SDK, be sure it has been
>installed.
> -- Configuring incomplete, errors occurred!
>
> I am not sure how to proceed since I am not using KDE as my DE and I am not
> developing apps for KDE..
>

KMyMoney is a KDE application, and to compile from source you would need 
to have a number of dependencies, "QGpgme" included.

However, if you are not familiar with KDE application development, it 
might be better for you to locate the Claydoh PPA, and you should find a 
recent KMyMoney release there.

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

--- Comment #9 from allan <agande...@gmail.com> ---
(In reply to NSLW from comment #8)
> (In reply to allan from comment #7)
> > I did fix this a while ago, following
> > https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got
> > side-tracked, and it was not committed.
> > 
> > The proposed patch looks, good, but I would make one change, in
> > "
> > securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row,
> > detail)->text().toUpper().trimmed();"
> > 
> > I would propose removing the '.toUpper()', allowing the user's
> > value/preference to be maintained.
> 
> That seems reasonable. Do you need me to send you another patch?

No, thanks.  I think we have enough.

Allan

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360747

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360747

allan <agande...@gmail.com> changed:

   What|Removed |Added

  Attachment #97981|[PATCH] Use parseLine() to  |[PATCH] CSV Importer
description|determine most likely   |detects more columns than
   |fieldDelimiter  |are assigned

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case

[allan via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360435

allan <agande...@gmail.com> changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #7 from allan <agande...@gmail.com> ---
I did fix this a while ago, following
https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got
side-tracked, and it was not committed.

The proposed patch looks, good, but I would make one change, in
"
securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row,
detail)->text().toUpper().trimmed();"

I would propose removing the '.toUpper()', allowing the user's value/preference
to be maintained.

-- 
You are receiving this mail because:
You are the assignee for the bug.