https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #487 from David Cook <dcook@prosentient.com.au> --- (In reply to Pedro Amorim from comment #486)

As stated above by Andrew Fuerste-Henry, we have a project to develop this functionality into Koha, some of the requirements overlap with what we already have here, but others differ, namely: - 'Hold groups' are referred to as 'HyperHolds'. This is but a naming divergence but possibly worth considering adopting as the naming of 'hold groups' already exist in Koha as stated by https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516#c275 - Only Staff members are able to create hold groups - This may be addressed by updating the DisplayAddHoldGroups sys pref to 'OPAC', 'Staff', 'OPAC and Staff', 'Disabled' - The creation of a hold group must be possible from the list of existing holds in a patron record page - I believe the idea here is a patron may place holds on multiple similar biblios without necessarily creating a 'group hold' themselves. Staff members are then able to group said existing holds together. From my understanding this is not possible with the current implementation. The current implementation only considers the creation of a group hold directly from the search results. - Holds remain counted separately for circ rule limits - This could possibly be addressed by a new 'Default hold groups policy' where one would be able to set 'A hold group is considered a single hold for circulation rules hold limits purposes'. If 'Yes', hold groups are treated as single holds for circ rules limit purposes, otherwise hold groups are ignored and each individual hold is considered for circ rules limit purposes. - Patron record page, 'Holds' tab, instead of having the '(part of a hold group)' link next to the hold title, have a new 'hold group' column that displays the hold group id, which can be sorted ASC or DESC. - The hold group (hold_groups table) also contains expiration date, future hold date, pickup location, suspension and changes made to the hold group reflect to the holds contained in it - REST API endpoints for hold groups CRUD is required

All of these (and others) I intend to do in follow-up bugs, but keeping within the community spirit, it would most definitely be more productive to first help move this patchset along, especially given the amount of interest and time already invested here given that this is, at the very least, the base of the functionality that we now require for the project.

This sounds good to me! Very compatible with what we've got here (and locally). -- You are receiving this mail because: You are watching all bug changes.