https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28869 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Marcel de Rooy from comment #5)
Just some related questions here.
Should we save authorised_values.id in connected fields? Perhaps theoretically, but it does not sound very practical at this point in our codebase. So NO.
Agreed.
Should we adjust other item fields that are of integer type connected to AV where the same problem actually may occur? Move them all to varchar(80)? It feels a bit like overkill? These are: | stack | tinyint(1) | # on this report | notforloan | tinyint(1) | | damaged | tinyint(1) | | itemlost | tinyint(1) | | withdrawn | tinyint(1) | | restricted | tinyint(1) |
IF doing so, we could look at default values. They are not completely consistent, since damaged and withdrawn default to 0. `restricted` tinyint(1) DEFAULT NULL COMMENT 'authorized value defining use restrictions for this item (MARC21 952$5)', `stack` tinyint(1) DEFAULT NULL, `ccode` varchar(80) DEFAULT NULL COMMENT 'authorized value for the collection code associated with this item (MARC21 952$8)', `location` varchar(80) DEFAULT NULL COMMENT 'authorized value for the shelving location for this item (MARC21 952$c)',
Standardizing the default values would be nice, but I am very hesitant about changing the datatype on the listed fields to varchar. My doubts are about the handling in our code and in reports. I know that we make numerical comparisons on these fields, like notforloan negative and positive values are treated differently within the codebase. Restricted = 1 has a special meaning. I would leave the status as is and only change stack, as it doesn't seem to belong in the list (not a status).
I thought about warning for a wrong value in an item field of type integer/date BEFORE saving. Now we can just enter something in various fields, save, get no warning and come back later to discover that our data is lost. E.g. the example of 127 for a higher number. (Coming back as 127 with a warning in the editor.) Or just 0 for a string.
I have helped a lot of people "fix" this problem over time, so better handling in the GUI would be desirable. Maybe instead of fixing the item editor etc. we should fix the authorised values editor instead.
But since this originates from AV. We should perhaps add a restriction THERE! Why not add an AV column that allows you to only enter tinyints instead of 80 char codes? If we solve it in AV, there will be no problem in items?
Agreed :) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.