Hi, An issue that's bugged me for a while is the fact that AddReserve() relies on the caller to set the priority of the request. That historically has meant that there are several different places in the code where the priority is calculated, and the code duplication means that there's a risk of it getting calculated slightly differently. Furthermore, there's the potential for a race condition if the patron or staff member takes a while to actually submit the hold request. The patch for bug 8918 offers the potential start of an improvement for this situation by defining a new central routine to calculate the priority, although at present CalculatePriority() is used in only one place. However, I'd like to suggest that rather than simply expanding the use of CalculatePriority(), that it instead by called by AddReserve() and that the $priority parameter of AddReserve() be removed. This would have the effect of pushing each new request to the end of the line (with variations for future holds and item-level requests). As near as I can tell, all of the places that call AddReserves() alreay implement this policy (including serials/routing-preview.pl, although indirectly). However, I would appreciate a check of that assumption. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org