Bug 40555

Summary: Items with empty itemtype cause issues
Product: Koha Reporter: Pedro Amorim <pedro.amorim>
Component: CirculationAssignee: Bugs List <koha-bugs>
Status: In Discussion --- QA Contact: Testopia <testopia>
Severity: normal    
Priority: P5 - low CC: david, gmcharlt, jonathan.druart, kyle, martin.renvoize, pedro.amorim, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33166
GIT URL: Initiative type: ---
Sponsorship status: --- Comma delimited list of Sponsors:
Crowdfunding goal: 0 Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function: Bookings
Attachments: Bug 40555: Consider possibility of item not having itemtype on effective_bookable

Description Pedro Amorim 2025-07-30 14:26:41 UTC
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).
Comment 1 Pedro Amorim 2025-07-30 14:32:02 UTC
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.
Comment 2 Pedro Amorim 2025-07-30 14:34:20 UTC
Created attachment 184897 [details] [review]
Bug 40555: Consider possibility of item not having itemtype on effective_bookable
Comment 3 Jonathan Druart 2025-07-31 09:43:16 UTC
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.
Comment 4 Pedro Amorim 2025-10-20 13:36:59 UTC
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
Comment 5 Jonathan Druart 2025-10-20 13:47:27 UTC
(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.
Comment 6 Pedro Amorim 2025-10-20 14:25:00 UTC
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.>>
Comment 7 Jonathan Druart 2025-10-20 14:39:28 UTC
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.
Comment 8 Pedro Amorim 2025-10-20 14:52:11 UTC
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.