https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36331
--- Comment #7 from Nick Clemens <[email protected]> --- (In reply to Marcel de Rooy from comment #4) > next unless > CanItemBeReserved($patron_with_reserve,$other_item,undef, > {ignore_hold_counts=>1})->{status} eq 'OK'; > # NOTE: At checkin we call 'CheckReserves' which checks > hold 'policy' > # CanItemBeReserved checks 'rules' and 'policies' which > means > # items will fill holds at checkin that are rejected here > > Stumbling over that note while looking here.. Why do we actually need that > check? Trying to understand altough we could say that it is outside scope ? > Perhaps. (In reply to Marcel de Rooy from comment #4) > next unless > CanItemBeReserved($patron_with_reserve,$other_item,undef, > {ignore_hold_counts=>1})->{status} eq 'OK'; > # NOTE: At checkin we call 'CheckReserves' which checks > hold 'policy' > # CanItemBeReserved checks 'rules' and 'policies' which > means > # items will fill holds at checkin that are rejected here > > Stumbling over that note while looking here.. Why do we actually need that > check? Trying to understand altough we could say that it is outside scope ? > Perhaps. I do think it is outside of the scope, it is really meant to be a for the coders - essentially this routine is more strict, but I think that makes sense. This has come up on other reports, we have two concepts: Can a hold be placed on this item Can this item fill a hold My patch here simply limits the holds checked against renewal to the ones that the item being renewed would fill. This is pre-existing logic that won't assume another item on the record can fill a hold that can't be placed (by a patron, staff can override) Librarians want this for the situation I describe in the test plan - a record with a mix of items that can and cannot be held. Generally these are new books, or 'lucky day' books as some libraries call them - books that won't be on hold so you get 'lucky' and find them in the library. These items cannot have holds, but currently holds can prevent their renewal - even with AllowRenewalIfOtherItemsAvailable (In reply to Marcel de Rooy from comment #5) > Also wondering (but very theoretical here) if walking thru items and holds > in another order could possibly produce other results.. But not for now :) Very true, perhaps once we get 35826 we could use that logic too: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35826 -- 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/
