[Koha-devel] RFC 3.2 - general hold request changes

[Galen Charlton]

Hi,

I've already sent out a couple of RFCs about hold requests and
friends, and will be sending out some more that relate to specific
customer projects for LibLime, but I wanted to toss out a few ideas
for general improvement.  A large number of bugs have been turned up
recently, most of which were postponed to 3.2, so I think the module
is in need of some attention beyond the specific enhancements to be
proposed.

First, the reserves table needs at least one more column to handle
item-level requests properly.  Right now, reserves.itemnumber serves
two purposes: (a) identifying the requested item if the hold is
item-level and (b) identifying the item selected to fill a title-level
request.  This is a problem because it can be hard to distinguish
between bib- and item-level requests, and impossible to do so once the
request is filled and the item is waiting on the hold shelf.  I
propose to replace reserves.itemnumber with two columns:

requested_itemnumber (NULL for bib-level requests, non-NULL otherwise)
supplied_itemnumber (non-NULL once the request is filled)

During a version upgrade, the value of reserves.itemnumber would be
moved to requested_itemnumber if the priority > 0, and to
supplied_itemnumber if the priority is 0.  This is not a perfect
heuristic, as a filled item-level request should set both columns, but
I'm not sure we can do much better.

Second, i think the reserveconstraints table needs to be removed.  It
appears to date to a time when a biblio could have more than one
bilbioitem, but now that the relationship is one-to-one, it cannot
serve its original purpose of limiting a request to only specific
formats attached to a bib.   Removing reserveconstraints would leave
Koha supporting bib-level and item-level requests.  If something in
between bib-level and item-level is still needed, I suppose that it
would have to be based on selecting which item types are suitable for
filling a request on a given bib - for example, if the library
attaches codex and audiobook items to the same bib and gives them
different item types, reservecontraints (or its successor) might
contain a list of item types.

Third, since larger Koha libraries can have hold request queues a
couple hundred patrons long or longer, I'm going to experiment with
ways of managing the priority value so that it is possible to fill
hold requests without having to touch every request in the queue, both
to aid performance and to possibly avoid bugs where multiple requests
for a given bib have the same priority.

Fourth, I want to add an auto_increment reserve_id column to reserves
to give us an opaque request ID to simplify FK relationships with
tables such as the successor to reserveconstraints and additional
tables that we may need as we extend the request system to handle
recalls and other types of requests.

Fifth, I want to do some work with C4::Reserves to cleanup the FIXMEs,
improve the POD, and add functions to separate handling when items can
be requested versus when they are available to fill hold requests.

Regards,

Galen
-- 
Galen Charlton
VP, Research & Development, LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709
skype: gmcharlt