https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516

--- Comment #486 from Pedro Amorim <pedro.amorim@openfifth.co.uk> ---
Thank you David. My preliminary testing notes of this patchset (some/all of it
confirm bugs you've already outline):

- Staff: Hold group modal (when clicking the "(part of a hold group link)")
contains out of date UI elements styling
- Staff: Hold group modal 'x' and 'close' button don't work.
- Staff: Created a hold group searching 'music' and picking 1st and 3rd
records. After checking in one item of a hold group and confirming, the item
became in transit, the other hold was not deleted (I would expect it to be
deleted as per the test plan)
- Staff: After the above, when visiting the holds queue page, I get a 500 error
with the following entry on the logs:
# Not an ARRAY reference at /kohadevbox/koha/circ/view_holdsqueue.pl line 58.
- OPAC: Using koha:koha user in ktd, when creating a hold group from the OPAC,
following the "Gairm" and "Clean code" example, I get the following error
message:
# One or more holds were not placed due to following errors: You have exceeded
the number of concurrent holds for this record
But if I place both holds without ticking the 'treat as hold group' checkbox,
both holds are correctly placed.
I was unable to follow the rest of the OPAC test plan.
- Staff: As above, when doing the same exercise on Staff UI, only 'Clean code'
hold goes through, 'Gairm' hold is never created. No error message shown.

-----------------------

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.
I'm in contact with David through DMs in MatterMost and want to help move this
forward.

-- 
You are receiving this mail because:
You are watching all bug changes.