Bug 5459 - merging records loses holds from one
Summary: merging records loses holds from one
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: master
Hardware: All All
: PATCH-Sent (DO NOT USE) critical (vote)
Assignee: Chris Cormack
QA Contact: Bugs List
URL:
Keywords:
Depends on:
Blocks: 8149
  Show dependency treegraph
 
Reported: 2010-11-30 17:49 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
7 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 5459 - Holds not being shifted when merging biblios (3.11 KB, patch)
2011-09-04 23:04 UTC, Chris Cormack
Details | Diff | Splinter Review
2 waiting (73.48 KB, image/png)
2011-09-06 14:32 UTC, Nicole C. Engard
Details
not waiting (100.98 KB, image/png)
2011-09-06 14:33 UTC, Nicole C. Engard
Details
Bug 5459 - Holds not being shifted when merging biblios (3.16 KB, patch)
2011-09-19 22:57 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 5459 - Holds not being shifted when merging biblios (3.54 KB, patch)
2011-09-19 23:05 UTC, Chris Cormack
Details | Diff | Splinter Review
1st title holds before merge (95.41 KB, image/png)
2011-09-27 16:39 UTC, Nicole C. Engard
Details
2nd title holds before merge (36.09 KB, image/png)
2011-09-27 16:39 UTC, Nicole C. Engard
Details
merged holds (94.10 KB, image/png)
2011-09-27 16:40 UTC, Nicole C. Engard
Details
merged holdings shows the two titles still in transit (177.60 KB, image/png)
2011-09-27 16:41 UTC, Nicole C. Engard
Details
Bug 5459 - Holds not being shifted when merging biblios (3.57 KB, patch)
2011-09-27 17:19 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 5459 - Holds not being shifted when merging biblios (3.59 KB, patch)
2011-09-27 17:23 UTC, Chris Cormack
Details | Diff | Splinter Review
1 for priority (39.77 KB, image/png)
2011-09-28 15:16 UTC, Nicole C. Engard
Details
Bug 5459 - Holds not being shifted when merging biblios (3.59 KB, patch)
2011-10-06 03:26 UTC, Chris Cormack
Details | Diff | Splinter Review
Bug 5459 - Holds not being shifted when merging biblios (3.77 KB, patch)
2011-10-06 03:28 UTC, Chris Cormack
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 5459 - Holds not being shifted when merging biblios (3.85 KB, patch)
2011-10-06 12:30 UTC, Nicole C. Engard
Details | Diff | Splinter Review
Bug 5459 - Holds not being shifted when merging biblios (3.89 KB, patch)
2011-10-12 09:57 UTC, Paul Poulain
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 2010-11-30 17:49:46 UTC
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.
Comment 1 Liz Rea 2011-02-21 20:56:01 UTC
This bug makes the bib-merge feature unusable for us in all but the most limited cases.
Comment 2 Nicole C. Engard 2011-06-09 16:09:20 UTC
Just a little nudge on this very critical issue - as Liz said, it makes the merge feature unusable.
Comment 3 Joe Atzberger 2011-06-10 15:52:48 UTC
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.
Comment 4 Nicole C. Engard 2011-06-10 16:27:35 UTC
While I am not in a library setting, this does sound agreeable to me.
Comment 5 Liz Rea 2011-06-11 02:54:48 UTC
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.
Comment 6 Liz Rea 2011-06-11 02:55:20 UTC
well that did not work at all. 

hrmph.

I'll attach a screenshot. 

*mutter*
Comment 7 Liz Rea 2011-06-11 02:56:54 UTC
http://screencast.com/t/xhZbFKWF1
Comment 8 Nicole C. Engard 2011-06-24 15:10:02 UTC
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.
Comment 9 Chris Cormack 2011-08-28 23:26:40 UTC
So the spec for this, is, transfer all holds, and reorder on the date the holds were placed?
Comment 10 Liz Rea 2011-08-29 18:35:21 UTC
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).
Comment 11 Chris Cormack 2011-09-04 21:16:25 UTC
Working on this now
Comment 12 Chris Cormack 2011-09-04 21:41:56 UTC
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
Comment 13 Chris Cormack 2011-09-04 23:04:13 UTC Comment hidden (obsolete)
Comment 14 Nicole C. Engard 2011-09-06 14:32:36 UTC Comment hidden (obsolete)
Comment 15 Nicole C. Engard 2011-09-06 14:33:09 UTC Comment hidden (obsolete)
Comment 16 Chris Cormack 2011-09-19 22:57:06 UTC Comment hidden (obsolete)
Comment 17 Chris Cormack 2011-09-19 23:05:46 UTC Comment hidden (obsolete)
Comment 18 Nicole C. Engard 2011-09-27 16:39:07 UTC Comment hidden (obsolete)
Comment 19 Nicole C. Engard 2011-09-27 16:39:47 UTC Comment hidden (obsolete)
Comment 20 Nicole C. Engard 2011-09-27 16:40:35 UTC Comment hidden (obsolete)
Comment 21 Nicole C. Engard 2011-09-27 16:41:24 UTC Comment hidden (obsolete)
Comment 22 Nicole C. Engard 2011-09-27 16:41:53 UTC
After applying this new patch the hold is not transferred from one title to the other - it's still lost.

Nicole
Comment 23 Chris Cormack 2011-09-27 17:19:04 UTC Comment hidden (obsolete)
Comment 24 Chris Cormack 2011-09-27 17:23:10 UTC Comment hidden (obsolete)
Comment 25 Chris Cormack 2011-09-27 17:23:43 UTC
My bad, in trying to avoid reordering items marked as waiting I caused them not to be merged at all.
Comment 26 Nicole C. Engard 2011-09-28 15:16:09 UTC
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.
Comment 27 Chris Cormack 2011-10-06 03:26:44 UTC Comment hidden (obsolete)
Comment 28 Chris Cormack 2011-10-06 03:28:27 UTC Comment hidden (obsolete)
Comment 29 Nicole C. Engard 2011-10-06 12:30:32 UTC Comment hidden (obsolete)
Comment 30 Ian Walls 2011-10-06 13:22:37 UTC
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?
Comment 31 Owen Leonard 2011-10-06 13:33:00 UTC
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.
Comment 32 Paul Poulain 2011-10-12 09:57:37 UTC
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>
Comment 33 Paul Poulain 2011-10-12 10:00:41 UTC
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 !
Comment 34 Ian Walls 2011-10-12 13:47:10 UTC
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.
Comment 35 Chris Cormack 2011-10-12 20:41:21 UTC
Pushed, please test

Needs a follow up to deal with a borrower having a hold on each biblio
Comment 36 Jared Camins-Esakov 2012-12-31 01:01:16 UTC
There have been no further reports of problems so I am marking this bug resolved.