Several authorised value categories have inherent limits on what values can be used. Bug 24288 adds text to the screen to tell you about these limits, but doesn't enforce them. It'd be good to just stop a user from saving a value that won't work.
+1
(In reply to Andrew Fuerste-Henry from comment #0) > Several authorised value categories have inherent limits on what values can > be used. Bug 24288 adds text to the screen to tell you about these limits, > but doesn't enforce them. It'd be good to just stop a user from saving a > value that won't work. It might be good to give specific cases here. On which form are you able to save values outside the range of an AV category?
You can create the authorised values without issue, but you cannot use them in items. items.damaged linked to DAMAGED only takes numerical AV codes. (datatype)
(In reply to Katrin Fischer from comment #3) > You can create the authorised values without issue, but you cannot use them > in items. items.damaged linked to DAMAGED only takes numerical AV codes. > (datatype) Correct. I can create an authorized value in the DAMAGED category that has the value "TORN". Koha allows the creation of that authorized value, and then will show TORN as an option when editing items. However, it will never actually save TORN on an item and will never explain why it's failed to do so. The answer to that lies over in the schema, which tells us items.damaged only holds a bit.
(In reply to Andrew Fuerste-Henry from comment #4) > (In reply to Katrin Fischer from comment #3) > > You can create the authorised values without issue, but you cannot use them > > in items. items.damaged linked to DAMAGED only takes numerical AV codes. > > (datatype) > > Correct. I can create an authorized value in the DAMAGED category that has > the value "TORN". Koha allows the creation of that authorized value, and > then will show TORN as an option when editing items. However, it will never > actually save TORN on an item and will never explain why it's failed to do > so. The answer to that lies over in the schema, which tells us items.damaged > only holds a bit. Okay. How to proceed? We could move damaged to varchar() as expected by Authorised Values? Or we could intercept this in storing the item? Or even before building the combo, but that could be quite generic code, so a bit harder? Or when loading the form in javascript (hide options with a non-numeric value)? Another idea?
The code for NOT_LOAN checks for < > etc. and I think we do this for those other values too. So maybe it makes more sense to keep them numeric and make the differences clear in the GUI
(In reply to Katrin Fischer from comment #6) > The code for NOT_LOAN checks for < > etc. and I think we do this for those > other values too. So maybe it makes more sense to keep them numeric and make > the differences clear in the GUI Agreed.