We've hit this recently on our demo installation, but I believe we've stumbled upon this in the past in different parts of Koha that may interact with Items (and Bookings, by extension).
The error log message is the following: GET /api/v1/preservation/waiting-list/items: unhandled exception (Mojo::Exception)<<Can't call method "bookable" on an undefined value at /usr/share/koha/lib/Koha/Item.pm line 1929.>> Produced when accessing: <staff_url>/cgi-bin/koha/preservation/waiting-list With one or more (?) items without an itemtype (or itype, depending on preference?) More analysis required.
Created attachment 184897 [details] [review] Bug 40555: Consider possibility of item not having itemtype on effective_bookable
IMO This is invalid. We have discussed on bug 33166 (and others) and decided that we should not deal with corrupted data. The bug here is to have the column null at the DB level.
Adding others to the discussion here. Can we please agree on a solution. We keep getting customers experiencing the issue fixed by this patch, this time when showing the items table on cgi-bin/koha/catalogue/detail.pl
(In reply to Pedro Amorim from comment #4) > Adding others to the discussion here. Can we please agree on a solution. We > keep getting customers experiencing the issue fixed by this patch, this time > when showing the items table on cgi-bin/koha/catalogue/detail.pl See bug 40777, this is the solution we should bring to end-users IMO.
At this point the bug title and submitted patch may no longer be 100% accurate, but these issues are all coming from the fact that an item does not have an item type set. To reproduce: 1) MARC21: Add 'TEST' as default value for 952$y for 'Fast add framework', handy link: <staff_url>/cgi-bin/koha/admin/marc_subfields_structure.pl?op=add_form&tagfield=952&tagsubfield=y&frameworkcode=FA#subyfield 2) Go to any record: <staff_url>/cgi-bin/koha/catalogue/detail.pl?biblionumber=76 3) Click 'Edit' -> 'Edit record'. Click 'Settings' and pick 'Fast add framework'. Click 'Save'. 4) Click 'New' -> 'New Item'. Notice the default value says 'Not an authorised value' but still lets you save. Click 'Save'. 5) Visit the same record again (repeat 2). 6) You get a table error, log error is the following: GET /api/v1/biblios/76/items: unhandled exception (Mojo::Exception)<<Can't call method "notforloan" on an undefined value at /kohadevbox/koha/Koha/Item.pm line 1556.>>
Yes, this is data inconsistency. We discussed it several times over the last years. We should not deal with those cases in the code, but prevent them to appear instead. Or at least tell the librarians something is not good in the data. That's why we have the search_for_data_inconsistencies script, and why I am suggesting to port the output to the UI on bug 40777. Another long term solution is to prevent such problems when saving a record, or editing/deleting an authorised value.
These are my suggestions on how to handle this problem: 1) 'MARC bibliographic framework test' needs to notify if a default value of a MARC framework does not match at least one value of the configured auth_val list. It doesn't do this currently. 2) About page 'System information' needs to at least have a message saying 'One or more items with an empty itemtype were found'. It doesn't do this currently. 3) When configuring the MARC framework, only allow a value that is part of the configured auth_val list to be set as default, not a free text input. 4) Finally, when adding a new item to a bib record, when the fallback to the configured default happens, verify, at that time, that the default value is actually an element of the configured auth_val list.