Bug 27977 - Internal server error when placing hold if previously uploaded records have no item type set
Summary: Internal server error when placing hold if previously uploaded records have n...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low major (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-17 19:38 UTC by Cindy Murdock Ames
Modified: 2023-07-01 18:16 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
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 Cindy Murdock Ames 2021-03-17 19:38:20 UTC
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)
Comment 1 Jonathan Druart 2021-03-18 10:45:47 UTC
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
Comment 2 Cindy Murdock Ames 2021-03-18 18:21:58 UTC
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.
Comment 3 Katrin Fischer 2021-03-23 07:43:00 UTC
(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.
Comment 4 Jonathan Druart 2021-04-15 10:07:34 UTC
I would suggest to set 952$y to the default value you want. Could that work for you?
Comment 5 Cindy Murdock Ames 2021-04-15 15:41:49 UTC
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.
Comment 6 Katrin Fischer 2023-07-01 18:16:00 UTC
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