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@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt