[Bug 33166] New: Can't call method "notforloan" on an undefined value when placing a hold
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33166 Bug ID: 33166 Summary: Can't call method "notforloan" on an undefined value when placing a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: julian.maurice@biblibre.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Steps to reproduce: 1. Create a biblio with no item type, and an item with no item type 2. Try to place a hold for this biblio You should get an "internal server error" message, and in the logs the following line: Can't call method "notforloan" on an undefined value at [...]/C4/Reserves.pm line 1446. -- 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=33166 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m, | |jonathan.druart+koha@gmail. | |com --- Comment #1 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Julian, we expect all items to have itemtypes now, so this is an INVALID I am afraid. You need to fix the data using the script for finding inconsistencies. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
From a user perspective, it looks like it's possible but then you get hit by
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33166 --- Comment #2 from Julian Maurice <julian.maurice@biblibre.com> --- Shouldn't Koha prevent creating biblio/item without itemtype then ? this internal server error without a clue about what's wrong -- 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=33166 --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- We have made the itemtype mandatory in the frameworks for MARC21 at least, not sure if the same applies to UNIMARC (I haven't checked), but of course this will be only the case for new installations. I think it makes sense to say it should be mandatory, but I am also not super happy about the errors it causes as we have a lot of libraries that are still missing itemtypes (from the past) We will probably try to clean this up with 22.11 as the problems it causes are getting more and more sever (like OPAC detail page exploding). -- 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=33166 --- Comment #4 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Katrin Fischer from comment #3)
We have made the itemtype mandatory in the frameworks for MARC21 at least, not sure if the same applies to UNIMARC (I haven't checked), but of course this will be only the case for new installations.
Ok, but MARC frameworks are modifiable... And even if they weren't, we can import biblio from other sources and mandatory fields are not checked in that case.
I think it makes sense to say it should be mandatory, but I am also not super happy about the errors it causes as we have a lot of libraries that are still missing itemtypes (from the past)
I think that as long as biblioitems.itemtype/items.itype is NULL-able, we cannot expect to always have a value there. -- 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=33166 --- Comment #5 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Julian, there are several places where we are not checking if the item type exists, and we decided to not fix them all but assume the data are correct instead. The script misc/maintenance/search_for_data_inconsistencies.pl is catching such inconsistencies.
Ok, but MARC frameworks are modifiable...
Yes, but you have hundreds of ways to make Koha explodes when you modify them. (In reply to Julian Maurice from comment #4)
I think that as long as biblioitems.itemtype/items.itype is NULL-able, we cannot expect to always have a value there.
Yes, you are right. That's is something we should fix. -- 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=33166 Koha Team University Lyon 3 <koha@univ-lyon3.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |23732 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23732 [Bug 23732] Hold rules checker: show matched rules and syspref values to help understand why a hold is possible or not -- 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=33166 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion CC| |dcook@prosentient.com.au --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #5)
(In reply to Julian Maurice from comment #4)
I think that as long as biblioitems.itemtype/items.itype is NULL-able, we cannot expect to always have a value there.
Yes, you are right. That's is something we should fix.
In that case, do we want to change the title of this bug to reflex that, or close this one and open a new one? -- 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=33166 --- Comment #7 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to David Cook from comment #6)
(In reply to Jonathan Druart from comment #5)
(In reply to Julian Maurice from comment #4)
I think that as long as biblioitems.itemtype/items.itype is NULL-able, we cannot expect to always have a value there.
Yes, you are right. That's is something we should fix.
In that case, do we want to change the title of this bug to reflex that, or close this one and open a new one?
Whatever you prefer. -- 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=33166 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Can't call method |Item type database fields |"notforloan" on an |should not be nullable |undefined value when | |placing a hold | Component|Hold requests |Architecture, internals, | |and plumbing -- 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=33166 Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emily.lamancusa@montgomeryc | |ountymd.gov --- Comment #8 from Emily Lamancusa <emily.lamancusa@montgomerycountymd.gov> --- Is there anything else that needs discussing here? Or should we set the bug back to NEW with the agreement that itemtype fields shouldn't be nullable? -- 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=33166 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I would be happy if we could avoid making the biblio-level itype mandatory. We don't set it usually, because of our union catalog situation. You cannot really predict the item type reliably from the bibliographic data and in the past it was not able to protect the field. -- 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=33166 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|23732 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23732 [Bug 23732] Hold rules checker: show matched rules and syspref values to help understand why a hold is possible or not -- 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=33166 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40555 -- 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