[Bug 27977] New: Internal server error when placing hold if previously uploaded records have no item type set
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 Bug ID: 27977 Summary: Internal server error when placing hold if previously uploaded records have no item type set Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: cmurdock@ccfls.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com 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) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #1 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 --- Comment #2 from Cindy Murdock Ames <cmurdock@ccfls.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 --- Comment #4 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I would suggest to set 952$y to the default value you want. Could that work for you? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|20.05 |master -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 --- Comment #5 from Cindy Murdock Ames <cmurdock@ccfls.org> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27977 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org