Bug 15679 - Reset item level hold back to record level hold without deleting and readding the hold
Summary: Reset item level hold back to record level hold without deleting and readding...
Status: RESOLVED DUPLICATE of bug 9834
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: 3.22
Hardware: All All
: P5 - low enhancement with 1 vote (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-27 01:23 UTC by HB-NEKLS
Modified: 2019-07-26 00:07 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description HB-NEKLS 2016-01-27 01:23:06 UTC
Right now, if a hold is tied to a specific item (for any number of reasons), and it needs to be set back to a title level hold, you have to delete and readd the hold.

This is cumbersome enough, but it's even more cumbersome when a record has multiple holds (especially 20+), and the hold has to be replaced and manually back in its original priority order. 

It would be nice if Koha could allow you to reset a hold back to record level after it's been placed, for all cases, including when it's in transit for a patron. 

Situations arise where an item arrives damaged or is lost in transit and a new item is needed to fulfill the hold. 

There should probably be a permission to control access to this proposed functionality, like the existing modify_holds_priority permission.
Comment 1 Hugh Rundle 2017-11-03 01:54:15 UTC
I agree, this is a major problem if a hold goes missing after it is allocated. There doesn't seem to be a simple way to 'de-allocate' a hold and return it to it's original state (i.e. a bib-level hold at the front of the queue).
Comment 2 Alex Buckley 2019-07-26 00:07:54 UTC
I believe this is a duplicate of bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9834

*** This bug has been marked as a duplicate of bug 9834 ***