https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20955
David Cook <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #9 from David Cook <[email protected]> --- It was driving me crazy trying to figure out why the hold wasn't being trapped, and it was because the "Hold policy" was set to "No holds allowed" for the branch library. -- That said, I might agree about the patch not being enough. As Katrin said, there's no way to know that this was an overridden hold. That said, that makes this extremely difficult to fix with the current code. (In reply to rpalermo from comment #8) > This is how we always thought it was supposed to work. If the hold is placed > with an override in Koha staff side, it should be filled at checkin. What > other reason would there be to override and place the hold if not to have it > get trapped? But I also agree with this. I mean if a hold exists, it must mean that it followed the rules at the time of its placement (whether via an override or not), so surely we should trap the hold. But... I guess we're looping through reserves at this point... and the branch with "No holds allowed" shouldn't fill the hold but a different branch could, so it wouldn't make sense to trap the hold in this case. -- Holds are a very challenging area... -- 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/
