---- Reported by cnighswonger@foundations.edu 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 nengard@gmail.com 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 cnighswonger@foundations.edu 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, ---, cnighswonger@foundations.edu, 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 chris@bigballofwax.co.nz 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. 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.
(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? Castro B, https://sparpedia.no
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.
Validation for dates exists now, so we can reduce this bug report to prices.
To be clear, would this bug validate the 952$g (Cost, normal purchase price) and 952$v (Cost, replacement price)? Bug 34169 added validation of monetary fields in acquisitions, but it did not include the item form used in acquisitions. In general it would be nice if it was included both in acquisitions and when editing/adding an item record to a bibliographic record.
(In reply to Esther Melander from comment #9) > To be clear, would this bug validate the 952$g (Cost, normal purchase price) > and 952$v (Cost, replacement price)? > > Bug 34169 added validation of monetary fields in acquisitions, but it did > not include the item form used in acquisitions. In general it would be nice > if it was included both in acquisitions and when editing/adding an item > record to a bibliographic record. In another four years this bug will turn 20... wow! I really do not recall much of anything about this as it has been so long. Reading back, it appears that work I did for LL never made it into the public repo. Sad. Maybe someone currently working on the project can comment.