Building on the 'reserve next available from a group' functionality implemented in bug 15516 the patches attached to this bug report should combine all the reserves in a hold-group on a biblio into a single line entry on the following interfaces: * reserve/request.pl * Reserves tab in the circ/circulation.pl * members/moremember.pl This will make the reserve queue display manageable and not too overly long
Created attachment 80317 [details] [review] Bug 21528: Display reserves in hold_group as single row in template
Created attachment 80319 [details] [review] Bug 21528: Display reserves in hold_group as single row in template Sponsored-By: Brimbank library, Australia
Created attachment 80376 [details] [review] Bug 21528: Single line for hold groups in intranet side Sponsored-By: Brimbank Library, Australia
Created attachment 80443 [details] [review] Bug 21528: Single line for hold groups in intranet side Sponsored-By: Brimbank Library, Australia
Created attachment 88042 [details] [review] Bug 21528: UNFINISHED PATCH
Created attachment 88124 [details] [review] Bug 21528: UNFINISHED PATCH
Comment on attachment 88124 [details] [review] Bug 21528: UNFINISHED PATCH Review of attachment 88124 [details] [review]: ----------------------------------------------------------------- ::: svc/holds @@ +103,2 @@ > itemtype_limit => $itemtype_limit, > + hold_group => Koha::Holds->search({ hold_group_id => $h->hold_group_id })->unblessed, This is buggy. I'd suggest changing it to the following: ( $h->hold_group_id ) ? Koha::Holds->search({ hold_group_id => $h->hold_group_id })->unblessed : undef If the hold doesn't have a hold group ID, all holds without a hold_group_id will be fetched. If a borrower has a high number of holds, and there are a high number of holds on the system, you'll be fetching and then transmitting a huge amount of data (the magnitude being megabytes instead of kilobytes). This uses up a lot of system memory and creates huge latency.