When you use the merge records tool, if both bibs have holds on them, when the merge is complete only the holds from the main record are kept and all others are lost.
This bug makes the bib-merge feature unusable for us in all but the most limited cases.
Just a little nudge on this very critical issue - as Liz said, it makes the merge feature unusable.
Doing anything with reordering holds can introduce some complexity. As a baseline, we might expect to resort the combined holds by their original datestamps. Is that agreeable? But all kinds of policy/priority mess can be interjected as well, like taking into account the current locations of the items, the owning branches, etc. I want to ignore that. I also want to explicitly ignore any idea of sending notices to the patrons about their new hold priority.
While I am not in a library setting, this does sound agreeable to me.
I believe that reordering by original date is a fine way to deal with it. Would it be possible to have some sort of display before the holds merge is completed "Here is how the holds queue is going to look after you click save: bib 1 date bib2 date Merged holds holda1 1/1 holdb1 1/2 holdA1 1/1 holda2 2/4 holdb2 1/15 holdB1 1/2 holda3 waiting holdb3 transit holdB2 1/15 holdA2 2/4\ holdB3 Transit holdA3 Waiting " Or somesuch? Or is that even necessary? My thinking is that it would let users say "oh gosh that won't work!" before it's completed and has to be manually undone.
well that did not work at all. hrmph. I'll attach a screenshot. *mutter*
http://screencast.com/t/xhZbFKWF1
Just an offer to help here - once the code is written to solve this problem I'll gladly add some text to the top explaining to those merging what will happen to holds.
So the spec for this, is, transfer all holds, and reorder on the date the holds were placed?
Yep. When merging holds, they should be merged by date placed. All I'd ask is that the notes be preserved, so if you have a hold with a note saying "re-placed <some later date>" the librarian can then put it back in the queue where it belongs (like at the top, in the case of an accidental deletion).
Working on this now
As part of the work, I have discovered that yep the current procedure is just to delete the biblio, which due to the foreign key constraints, kills the holds on it too. So the holds will have to be shifted before the delete occurs. Working on a patch now
Created attachment 5302 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed.
Created attachment 5317 [details] 2 waiting Alright this is almost ready. Before merging I had 2 items marked as waiting.
Created attachment 5318 [details] not waiting after merging the items are still waiting but the pull down has them listed as 1 and 2 and not waiting anymore.
Created attachment 5467 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting are not reordered.
Created attachment 5468 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting are not reordered.
Created attachment 5611 [details] 1st title holds before merge This is the list of holds on one title before the patch (note that 2 items are 'in transit')
Created attachment 5612 [details] 2nd title holds before merge This is the second title before the merge.
Created attachment 5613 [details] merged holds We're missing the hold from the second title on the merged bib and the 'in transit' status has gone away from the holds tab.
Created attachment 5614 [details] merged holdings shows the two titles still in transit After the merge, the in transit status is still there in the holdings table, just missing from the holds tab.
After applying this new patch the hold is not transferred from one title to the other - it's still lost. Nicole
Created attachment 5617 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered.
Created attachment 5618 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered.
My bad, in trying to avoid reordering items marked as waiting I caused them not to be merged at all.
Created attachment 5629 [details] 1 for priority We are so close!! Now it merges and keeps the transit status but shows 1 as the priority for all people.
Created attachment 5726 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered.
Created attachment 5727 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered.
Created attachment 5732 [details] [review] [SIGNED-OFF] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered. Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>
Minor issue: if a single borrower has both merging titles on hold, this patch does not reduce the two lines in reserves to one. This has some implications: a) the holds priority order can be adjusted safely, no issues there b) when the hold is marked 'waiting' for the patron, BOTH lines are changed to waiting; the rest of the priority list is okay c) but when the material is actually checked out to them, only one of the lines is marked "filled". The other is put back into first-place priority! This issue will come up any time a borrower has multiple holds on the same title, so this does extend beyond the scope of this particular issue. It is set to be addressed in the Holds Rewrite project. Once we have a primary key on reserves, this should no longer be an issue. In the meantime, is this a common enough problem to prevent this patch from being integrated? Adding this will make merge actually usable in most every case but this fringe, which is a vast improvement. But I don't want to set libraries up for failure, even in a rare case. Thoughts?
I think the fix is important enough to get approved despite the shortcoming. I think that case is probably not very common, and not a serious problem at that. It's just a minor inconvenience.
Created attachment 5848 [details] [review] Bug 5459 - Holds not being shifted when merging biblios Holds are now shifted and reordered by date placed. Holds already marked waiting, or in transit are not reordered. Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com> Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
QA comment : no comment, good description, good code About Ian's comment, I agree with owen, and add that if a patron has placed 2 holds on 2 different biblios with the same title (if the biblios are merged, it means that's the same document, right ?) then there's a problem with the patron ;-) The case of merging 2 biblios both having hold is uncommon, the case to have 2 holds placed by the same patron will be more than rare, it may never happend !
If a patron is very interested in a title, they may very well have placed holds on every biblio they could find, in an effort to get the material as quickly as possible, so I don't think this scenario can be ignored. However, given that this patch fixes a profound problem with merge (one that made it unusable for many libraries), and that the breakage is not immediate, but rather on hold-fill of the duplicate listing, I think it's safe to mark this one as Passed QA. Many other changes to reserves are currently on my list for 3.6; I'd like to revisit this issue when those changes have been processed, to see if it changes the landscape. In the meantime, folks will need to be made aware of this possibility, and that a manual check of the holds priority list will be required to scan for any double entries.
Pushed, please test Needs a follow up to deal with a borrower having a hold on each biblio
There have been no further reports of problems so I am marking this bug resolved.