Bug 8723 - holds don't transfer when moving items
Summary: holds don't transfer when moving items
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Jonathan Druart
QA Contact:
URL:
Whiteboard:
Keywords:
: 6645 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-09-04 17:01 UTC by Nicole C. Engard
Modified: 2016-06-21 21:38 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Bot Control: ---
When did the bot last check this:
Who signed the patch off:
Text to go in the release notes:


Attachments
Bug 8723: Cover the existing behavior (3.24 KB, patch)
2015-07-10 14:24 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 8723: Update the reserves table for item-level holds (4.82 KB, patch)
2015-07-10 14:24 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 8723: Update hold_fill_targets, tmp_holdsqueue and linktracker tables (1.28 KB, patch)
2015-07-10 14:24 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 8723: Cover the existing behavior (3.30 KB, patch)
2015-07-18 14:10 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 8723: Update the reserves table for item-level holds (4.87 KB, patch)
2015-07-18 14:10 UTC, Nick Clemens
Details | Diff | Splinter Review
Bug 8723: Update hold_fill_targets, tmp_holdsqueue and linktracker tables (1.34 KB, patch)
2015-07-18 14:10 UTC, Nick Clemens
Details | Diff | Splinter Review
[PASSED QA] Bug 8723: Cover the existing behavior (3.37 KB, patch)
2015-09-07 20:26 UTC, Katrin Fischer
Details | Diff | Splinter Review
[PASSED QA] Bug 8723: Update the reserves table for item-level holds (4.94 KB, patch)
2015-09-07 20:26 UTC, Katrin Fischer
Details | Diff | Splinter Review
[PASSED QA] Bug 8723: Update hold_fill_targets, tmp_holdsqueue and linktracker tables (1.40 KB, patch)
2015-09-07 20:26 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nicole C. Engard 2012-09-04 17:01:50 UTC
When using the attach item feature, if the item being moved/attached has an item specific hold on it, the hold does not transfer.  It remains on the patron's record but is still linked to the original bib record making it impossible to find/delete/confirm.

Nicole
Comment 1 Paul Poulain 2012-11-21 16:17:42 UTC
Nicole, I don't understand why it's a bug ?
If a patron place a hold on "the two towers", and the item moved was, in fact a "twilight" book, moving the hold should stay for "the two towers", isn't it ?

unless you're talking of a waiting hold, you'll confirm. And in this case, yes, it must be fixed... (and that will be tricky: we can't just move the hold, because the patron reserved "the two towers". So we have to cancel the hold and warn the patron. Or attach another item to the hold. yes, that will be tricky to fix...

(my feeling is that a quick workaround would be to reset the hold to non-"W" status)
Comment 2 Nicole C. Engard 2012-11-21 16:31:46 UTC
The problem is that the hold is 'item specific' - not a hold on the next available and so you end up with an orphaned hold because the reserves table still has a hold on that itemnumber, but the wrong biblionumber - so if this instance the hold should be moved to the right biblionumber or the itemnumber should be removed from the hold and the hold made on the bib level instead of item specific.

Nicole
Comment 3 Paul Poulain 2012-11-21 16:46:36 UTC
(In reply to comment #2)
> The problem is that the hold is 'item specific' - not a hold on the next
> available and so you end up with an orphaned hold because the reserves table
> still has a hold on that itemnumber, but the wrong biblionumber - so if this
> instance the hold should be moved to the right biblionumber or the
> itemnumber should be removed from the hold and the hold made on the bib
> level instead of item specific.
That would solve the technical problem. But the library will still have to explain that the user placed a hold on 'the two towers' and get '50 shades of grey'.
Well, the use case for moving an item is also that you've duplicate biblio records, so maybe the use case 'I place a hold on the 2 towers and get 50 shades of grey' is rare enough to be managed manually.
do you agree ?
Comment 4 Nicole C. Engard 2012-11-21 17:10:05 UTC
Managed manually how?  Right now there is no way to move that hold other than to alter the db directly (hence the bug report).  I do agree with you that if the patron places a hold on one book they should get that book and so I suggest that when you attach/move an item Koha removed the itemnumber reference from reserves and leaves the biblionumber reference.  

Anyone else have any ideas?
Comment 5 Liz Rea 2012-11-21 20:10:55 UTC
This is *definitely* a bug. 

People don't usually move items from a bib with one title to a bib with another, because, well, items, by their very nature, don't change title (broad, but justifiable, generalization).

I agree with Nicole that if you have an item with an item level hold, the hold should go with the item, the hold should not stay with the bib. The issue of "you could attach an item to the wrong title" is a human error, not a technical one, and should be fixed by the human.

Plus, if the hold moved with the item to the new bib, if someone made an error, it's easy enough to fix it by simply moving the item back to it's original bib, no harm, no foul.
Comment 6 Katrin Fischer 2012-11-24 18:48:49 UTC
I agree with Liz - an item level hold should move with the item.
Comment 7 Liz Rea 2013-01-06 21:11:49 UTC
Bump - this needs some love, deduping is a pain without this.
Comment 8 Owen Leonard 2013-08-13 20:00:23 UTC
*** Bug 6645 has been marked as a duplicate of this bug. ***
Comment 9 Galen Charlton 2014-05-06 17:43:02 UTC
It's not just item-level hold requests -- it's also bib-level hold requests that have been captured.

The following tables definitely should be updated when an item is moved to a different bib:

reserves
hold_fill_targets
tmp_holdsqueue
linktracker

The following tables perhaps should be updated:

aqorders_items
reserveconstraints
import_items
Comment 10 Jonathan Druart 2015-07-10 14:24:50 UTC Comment hidden (obsolete)
Comment 11 Jonathan Druart 2015-07-10 14:24:53 UTC Comment hidden (obsolete)
Comment 12 Jonathan Druart 2015-07-10 14:24:57 UTC Comment hidden (obsolete)
Comment 13 Jonathan Druart 2015-07-10 14:27:21 UTC
(In reply to Galen Charlton from comment #9)
> It's not just item-level hold requests -- it's also bib-level hold requests
> that have been captured.
> 
> The following tables definitely should be updated when an item is moved to a
> different bib:
> 
> reserves
> hold_fill_targets
> tmp_holdsqueue
> linktracker

Agreed and done.

> The following tables perhaps should be updated:
> 
> aqorders_items

No biblionumber field.

> reserveconstraints

It will be removed by bug 9809.

> import_items

Maybe, but I don't understand what to do here.
Comment 14 Nick Clemens 2015-07-18 14:10:06 UTC Comment hidden (obsolete)
Comment 15 Nick Clemens 2015-07-18 14:10:14 UTC Comment hidden (obsolete)
Comment 16 Nick Clemens 2015-07-18 14:10:19 UTC Comment hidden (obsolete)
Comment 17 Nick Clemens 2015-07-18 14:11:31 UTC
I can verify all behavior except linktracker.  I turned on trackclicks and clicked and clicked but cannot figure out how to populate the table.  Will retest if anyone has insight
Comment 18 Katrin Fischer 2015-09-07 20:25:11 UTC
I confirmed the linktracker update works correctly, to test:
- Activate TrackClicks
- Catalog an URL each in 856 and in 952$u
- Open each link in the OPAC
- Move item
- Check linktracker table: item link will have moved, record level link did not
Comment 19 Katrin Fischer 2015-09-07 20:26:05 UTC
Created attachment 42439 [details] [review]
[PASSED QA] Bug 8723: Cover the existing behavior

This patch cover the MoveItemFromBiblio subroutine

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 20 Katrin Fischer 2015-09-07 20:26:12 UTC
Created attachment 42440 [details] [review]
[PASSED QA] Bug 8723: Update the reserves table for item-level holds

If an item is moved from a biblio to another, the holds should be
updated too.

See discussion on the bug report for more information.

Test plan:
1/ Place a item-level hold on biblio1
2/ Move the item to biblio2
3/ Confirm that the hold still exists and point to the biblio2

This patch should not change the existing behavior for bib-level holds.

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 21 Katrin Fischer 2015-09-07 20:26:16 UTC
Created attachment 42441 [details] [review]
[PASSED QA] Bug 8723: Update hold_fill_targets, tmp_holdsqueue and linktracker tables

Same as previous patch for 3 other tables.

Test plan:
Same as before but the hold should exist to the 3 tables before the
move.

Signed-off-by: Nick Clemens <nick@quecheelibrary.org>

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 22 Tomás Cohen Arazi 2015-09-16 13:53:45 UTC
Patches pushed to master.

Good job Jonathan!
Comment 23 Chris Cormack 2015-09-22 17:34:54 UTC
Pushed to 3.20.x will be in 3.20.4
Comment 24 Liz Rea 2015-09-22 23:59:53 UTC
Pushed to 3.18.x will be in 3.18.11