[Kmymoney-devel] [Kmymoney] Is this a bug?

Allan agander93 at gmail.com
Sat Mar 24 11:03:42 UTC 2012


On 24/03/12 08:27, Thomas Baumgart wrote:
> On Friday 23 March 2012 22:18:31 Allan wrote:
>> On importing a csv file, an incorrect column was used for the 'amount'
>> field, which in fact contained a string which included a couple of
>> values.  The string was accepted, and the amount became the
>> concatenation of the two values, resulting in a huge value.
>>
>> I realised that it would be wise to test for valid values, and started
>> to think about validation.  Knowing that MyMoneyMoney converted text to
>> a MyMoneyMoney value, and, not wanting to reinvent the world, I looked
>> to see if there was a validity test, but found none, so looked in
>> qifimportreader(), and there did not appear to be a specific test there,
>> either.
>>
>> So, I imported the following qif file -
>>
>> !Account
>> NtestG
>> TBank
>> ^
>> !Type:Bank
>> D1/9/00
>> U524.91
>> TThis234.56isrubbish24.91
>> CX
>> POpen
>> ^
>>
>> It was imported successfully, with the result being a value of
>> 2,345,624.91!  So, that was exactly the same sort of result the csv
>> import produced.
>>
>> Of course, a qif file 'T' line is expected to have a genuine value, and
>> if it is incorrect, then the supplier is at fault.  Similarly for the
>> csv import, but because an extra step involving the user in selecting
>> the correct column is required, the risk is greater.
>>
>> How far should one go in validation?  Should qif import also validate?
>
> These things (checks) are now located in libalkimia code. There we have code
> like the following:
>
>    // different decimal symbol
>    m = new AlkValue(QLatin1String("x1.234,568 EUR"), QLatin1Char(','));
>    QVERIFY(m->toString() == QLatin1String("154321/125"));
>
> which allows to convert a value enclosed by text (mainly currency symbols or
> names). I admit, that this is a valid method to extract 'number' from the
> "text number text" input, but there is no validation againt a "text number
> text number text ..." input.
>
> The way it is implemented is to remove non-numeric characters from the input
> resulting in the concatenation of the numeric parts as you see them.
>
> Would you like to open a bug on the libalkimia product if you think it does
> not work correct. Otherwise, I would see a more details check in the CSV/QIF
> importer as I don't want to tighten the rules deep in the hierarchy too much.
>
> BTW: MyMoneyMoney simply encapsulates AlkValue in this respect.

So far as csv is concerned, because of the increased likelihood of error 
through user mistake, I think that validation should be done as early as 
possible, and as the text does not get converted to MyMoneyMoney until 
import actually starts, the check should be in the plugin.  There, the 
user can be alerted to his mistake at once, rather than after a few more 
interactions.  I'll raise a bug against the plugin.  There's a good 
validity check in QString.toDouble.

So far as QIF is concerned, it's probably reasonable to expect an 
imported file to contain a valid amount where one is expected.

> p.s. Also, this is more a developer question/discussion which actually belongs
> to another list ;)

Oops.  That was the intention.  I'll copy this email to the developer list.

Allan


More information about the KMyMoney-devel mailing list