[Koha-bugs] [Bug 4045] No check for maximum number of allowed holds.

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Feb 14 13:52:01 CET 2012


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4045

--- Comment #16 from Kyle M Hall <kyle.m.hall at gmail.com> 2012-02-14 12:52:01 UTC ---
I've been looking at the code, and there seems to be a fundamental flaw with
having having the the maximum reserves in the issuingrules table. Issuing rules
are defined by a combination of Branch Code, Patron Category, and Item Type. 

The problem is the item type. Most holds are placed at a bibliographic level,
and bibs in and of themselves, have no item type. Each bib can have attached
items of multiple item types. 

Furthermore, there was also a new system pref added, ReservesControlBranch,
which is supposed to define whether to use the patron's home library or the
item's home library, again, there can be multiple items each with a different
home library attached to a bib.

So, unless all item's attached to a bib are not hold-able based on the issuing
rules, we cannot disallow a bib level hold to be placed on the record.

Of Note: It does appear that the smart rules correctly disallows the placing of
item level holds, but does nothing for bib level holds. Even if all the items
on a record disallow item level holds, if a borrower has a bib level hold on
the record, and one of those items is returned, Koha will try to use it to
fulfill the hold ( even though it was specifically not hold-able ).

I am reticent to remove issuingrules.holdsallowed, as that would be going
backwards, not forwards. Removing this would probably cause serious problems
for any library that has been using it.

Here is the best solution I can come up with:
1) Re-add maxreserves ( renamed to MaxReserves ) to updatadatabase.pl

2) Use the hybrid approach that was previously decided against. Really, there
should be a way to define a maximum total number of holds, even if there is a
specific holds limit for a given Library/Patron/Item Type combination.

3) When an item was returned, and is about to fill a hold for a borrower, check
to see if that item was specifically hold-able for that person or not. If not,
either skip trying to use it to fulfill a hold, or keep going down the list of
people with holds for that bib until we find one that could have put an item
level hold on it, or until there is no one left.

The commit for this was added on Aug 24, 2009, in commit
3c741d2376e939dea0554a05eddd4f9e9b2d9449. It's amazing that this went
unreported for a year, and went three years without a solution.

-- 
Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are watching all bug changes.


More information about the Koha-bugs mailing list