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)

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

(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 ?

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?

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.

I agree with Liz - an item level hold should move with the item.

Bump - this needs some love, deduping is a pain without this.

*** Bug 6645 has been marked as a duplicate of this bug. ***

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

(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.

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

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

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>

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>

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>

Patches pushed to master.

Good job Jonathan!

Pushed to 3.20.x will be in 3.20.4

Pushed to 3.18.x will be in 3.18.11