https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42934

--- Comment #1 from Paul Derscheid <[email protected]> ---
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.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to