https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=31314 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934 --- Comment #1 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 201145 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201145&action=edit Bug 42934: Fix home/holding_library croak on NULL branch items.homebranch and items.holdingbranch are nullable foreign keys (is_nullable => 1, DEFAULT NULL), but Koha::Item->home_library and ->holding_library pass the (undef) DBIC relationship straight to Koha::Library->_new_from_dbic, which croaks with "DBIC result _type isn't of the _type Branch". This is a regression. Until Bug 31314 (commit e627b437dc54, 2022) the accessors were: Koha::Libraries->find( $self->homebranch() ); and Koha::Objects->find returns undef for a NULL/undef key, so a NULL branch yielded undef. Bug 31314's "use result objects" performance refactor replaced that with: Koha::Library->_new_from_dbic( $self->_result->homebranch ); which croaks on the undef relationship, silently dropping the NULL-tolerance the find() form had. The sibling nullable-FK accessors in the same class (checkout, serial_item, etc.) guard with "return unless $rs"; these two were missed. This surfaces as a 500 on GET /api/v1/biblios/{biblio_id}/items (the catalogue detail items table) for any item whose homebranch or holdingbranch is NULL. Item creation always sets these columns and Koha::Item->store never defaults them, so the NULL state is only reachable via out-of-band data (SQL import/migration) - which Koha already recognises as a data inconsistency (Koha::Database::DataInconsistency::invalid_item_library). Guard the accessors as their sibling nullable-FK accessors already do: return undef when the relationship is empty. to_api serialises the undef embed as null (_handle_to_api_child). Test plan: 1. prove t/db_dependent/Koha/Item.t => the new subtest 'home_library() and holding_library() with NULL branch' fails with "DBIC result _type isn't of the _type Branch" 2. Apply this patch 3. prove t/db_dependent/Koha/Item.t => green To reproduce the original 500 in the UI instead: 1. UPDATE items SET holdingbranch = NULL WHERE itemnumber = <X>; 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 (affected item has empty home/holding library) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934 --- Comment #3 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Alright, thanks for taking a look, joubu :) -- You are receiving this mail because: You are watching all bug changes.