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
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
