https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42935 --- Comment #1 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 201162 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201162&action=edit Bug 42935: _status should not croak when an item's itemtype is missing Koha::Item::_status does $self->item_type->notforloan, but item_type (Koha::ItemTypes->find( effective_itemtype )) can return undef. With item-level_itypes enabled, an items.itype holding a non-null code that is absent from the itemtypes table resolves to that code via effective_itemtype, and Koha::ItemTypes->find() then returns undef. items.itype has no enforced FK to itemtypes, so this is reachable with out-of-band data (SQL import/migration). A NULL items.itype does not trigger this: effective_itemtype falls back to the biblio-level itemtype. The problem is specifically a non-null code with no matching itemtype. Like the home_library/holding_library case, this surfaces as a 500 on GET /api/v1/biblios/{biblio_id}/items (the catalogue detail items table). Cache the item_type lookup (per the existing TODO) and guard the itemtype-level notforloan check, mirroring the existing guard in effective_not_for_loan_status, so a missing itemtype no longer dies. Test plan: 1. prove t/db_dependent/Koha/Item.t => the new subtest '_status() with a missing item type' fails with 'Can't call method "notforloan" on an undefined value' 2. Apply this patch 3. prove t/db_dependent/Koha/Item.t => green To reproduce the original 500 in the UI instead (item-level_itypes on): 1. UPDATE items SET itype = 'NOPE' WHERE itemnumber = <X>; -- not in itemtypes 2. Open that record's detail page; the holdings table fails to load and the plack log shows the croak above 3. Apply this patch and koha-plack --restart kohadev 4. Reload; the holdings table loads -- You are receiving this mail because: You are watching all bug changes.