Bug 2635 - Allow validation of item fields (price, dates)
Summary: Allow validation of item fields (price, dates)
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: PC All
: P5 - low normal (vote)
Assignee: Chris Nighswonger
QA Contact:
URL: cgi-bin/koha/cataloguing/additem.pl
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-23 01:50 UTC by Chris Nighswonger
Modified: 2019-07-08 08:08 UTC (History)
6 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 00:53:44 UTC


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

Comment 1 Liz Rea 2012-05-02 16:03:26 UTC
This is still a bug in 3.8.
Comment 2 Katrin Fischer 2015-01-06 18:13:20 UTC
Data validation of entry in 'price' fields is currently not done.
Comment 3 Marc Véron 2015-03-24 07:15:10 UTC
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.
Comment 4 Jesse Maseto 2016-07-28 13:46:17 UTC
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.
Comment 5 Katrin Fischer 2018-05-16 00:15:58 UTC
(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.
Comment 6 Castro B 2019-07-08 02:43:37 UTC
(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
Comment 7 Katrin Fischer 2019-07-08 08:08:54 UTC
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.