Bug 40979 - Item group level holds are not shown correctly on Holds to pull
Summary: Item group level holds are not shown correctly on Holds to pull
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 24857
Blocks:
  Show dependency treegraph
 
Reported: 2025-10-09 07:03 UTC by Marcel de Rooy
Modified: 2025-10-09 10:04 UTC (History)
5 users (show)

See Also:
GIT URL:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel de Rooy 2025-10-09 07:03:48 UTC
Available item count is incorrect.
Barcodes, call numbers, etc.

circ/pendingreserves probably needs another refactoring?
Comment 1 Marcel de Rooy 2025-10-09 08:50:05 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.
Comment 2 Marcel de Rooy 2025-10-09 10:04:16 UTC
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.