Summary: | Item group level holds are not shown correctly on Holds to pull | ||
---|---|---|---|
Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | normal | ||
Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, kyle, lisette, tomascohen |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26646 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 24857 | ||
Bug Blocks: |
Description
Marcel de Rooy
2025-10-09 07:03:48 UTC
In pendingreserves we are filtering the barcodes for the item groups, but do not filter callnumbers and other columns. But if there is a biblio level hold, we should not. The whole algorithm has been severely affected by item groups. This comes from a refactoring before item groups btw: my $all_holds = { map { $_->biblionumber => $_ } @{ Koha::Holds->search( { reserve_id => [ values %$holds_biblios_map ] }, { prefetch => [ 'borrowernumber', 'itembib', 'biblio', 'item_group' ], } )->as_list } }; But what does it exactly do? If we have multiple holds on a biblionumber, the map statement effectively discards all holds but one for each biblio in the resulting hash. So the name $all_holds is misleading! How effective is the prefetch here btw? But some lines later, we are doing: my $res_info = $all_holds->{$bibnum}; Note that the reserve we are using here seems to be the first one we found! And we will make further decisions based on only that hold. (When testing, it was the first one. But the code depends on map creating a hash, where the order is not preserved.) Like this test: if ( $res_info->item_group ) { Yeah, it could have an item group. But that test should not be based on one hold. |