[Koha-bugs] [Bug 28869] If authorized values for STACK (shelving control number) are > 127 things explode

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28869

--- Comment #7 from Katrin Fischer <katrin.fischer at 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.