---- Reported by email@example.com 2008-09-23 13:50:58 ----
Adding a non-digit char to either cost field on the add/edit item form causes data corruption due to storing the item cost info in biblioitems.marcxml (longtext) as well as items.cost and items.replacementcost (both integer). Thus if we enter '$10.00' the items fields end up NULL while '$10.00' is stored in the marcxml field. This causes problems when item data is retrieved from the items table rather than the biblioitems.marcxml record.
One fix is to check the data submitted for that field for chars other than digits and return an error to the user if such chars exist. I am submitting a patch to do this.
---- Additional Comments From firstname.lastname@example.org 2009-12-17 01:14:02 ----
Using a symbol in the cost field (ex: $3) now makes the system display 0.00 - and also has 0.00 in the xml - shouldn't an error appear instead? or is this the intended behavior?
---- Additional Comments From email@example.com 2009-12-17 15:54:28 ----
<chris_n2> re http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2635
<munin> Bug http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2635 normal, PATCH-Sent, ---, firstname.lastname@example.org, NEW, Adding non-digit chars to cost fields in items causes data corruption
<chris_n2> this was work I did for LL and submitted a patch, but cannot see that it was ever committed
<chris_n2> unfortunately I no longer have the work
<chris_n2> and I'm not sure what the intended behavior is atm... sorry... :-(
--- Bug imported by email@example.com 2010-05-21 00:53 UTC ---
This bug was previously known as _bug_ 2635 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2635
Actual time not defined. Setting to 0.0
This is still a bug in 3.8.
Data validation of entry in 'price' fields is currently not done.
I think dates should be validated as well.
With current master (3.19.00.016) it is possible to enter something like 'blablabla' or '2004' in 'd - Date acquired' and 'w - Price effective from'.
Both result to a value '0000-00-00' in the data table.
Wondering if this is part of this bug?
We are seeing when we put a price in for the original purchase price it gets saved as a 1 when the value has a comma in it.
Edit an item, add 1,345.80 and click save. It gets saved as a 1. If you enter 1345.80 it saves correctly.
(In reply to Jesse Maseto from comment #4)
> Wondering if this is part of this bug?
> We are seeing when we put a price in for the original purchase price it gets
> saved as a 1 when the value has a comma in it.
> For example
> Edit an item, add 1,345.80 and click save. It gets saved as a 1. If you
> enter 1345.80 it saves correctly.
Hi Jesse, I think this is more related to bug 12310, bug 18723 and bug 19521. Koha doesn't always work well with commas.
(In reply to Katrin Fischer from comment #5)
> Koha doesn't always work well with commas.
Hi Katrin so what do you suggest?
For now I suggest always using the format: 12.00 and avoid commas when entering monetary information in any spot in Koha. Long term I'd like us to support different formats, like we do for dates for example. There are 2 different opinions discussed here: one is an apporach to allow to enter in different formats and have Koha parse what it means. The other is have the input format follow the display format.
And yes, validation would be nice. I was just saying that entering data , should be avoided for now to avoid bad behaviour.