This is a weird one. If a batch of records are uploaded through the Stage MARC for import tool, and the items have no item type set, an Internal Server Error happens when staff tries to place a hold on any records cataloged *after* that, even if they do have an item type set. I stumbled upon this when staff imported some barebones "on order" records from Baker & Taylor and forgot to use the MARC modification template I'd created for them to set the item type, homebranch, holdingbranch, etc. Later a staff member at another library cataloged some items manually and tried placing a hold on one of them and got the Internal Server Error. In the logs, I see "Can't call method "notforloan" on an undefined value at /usr/share/koha/lib/C4/Reserves.pm line 1349" when the ISE occurs. Also it doesn't seem to happen every time, but what clued me in was another error when attempting to place a hold, about an item not having an itemtype set from a completely unrelated record. I investigated that and found that it was in the batch with no item type set. To reproduce: - Upload a batch of records with no item type set - Catalog some additional items - Try to place a hold on one of the items cataloged in the last step, via the staff interface (haven't tested with the public catalog)
Itemtype is mandatory, it must be a valid value defined in the system. You can find the problematic records running the following maintenance script: % perl misc/maintenance/search_for_data_inconsistencies.pl
That is true, but shouldn't the MARC staging tool set it to the default value to help prevent this? In my default framework there is a default value set.
(In reply to Cindy Murdock Ames from comment #2) > That is true, but shouldn't the MARC staging tool set it to the default > value to help prevent this? In my default framework there is a default > value set. The default values only work on adding a new record, if you overwrite them to say "empty" they are not going to be set automatically to a value. I think we could maybe get away with this change in behavior if we also said it has to be a mandatory field that cannot be empty or even limit to item type? Otherwise there are probably use cases where this might be an unwanted behavior.
I would suggest to set 952$y to the default value you want. Could that work for you?
Yes, that would work. 952y is also set as mandatory in my default framework, I would guess that it is in most libraries' frameworks, so a check to see if it was mandatory and if so making sure it has data would work too, if I'm understanding things here correctly.
Maybe ApplyFrameworkDefaults could be extended for staged MARC importing? But we also need better error management on imports: Bug 21272 - MARC import should warn about mis-matched branch and item-type fields in 952 during staged import