Merge merge two catalogue records that are added to different lists. The resulting merged record will be included only in the list of the master record, and not in the list of the deleted record. The same thing applies also when the master record is not included in any list, but the deleted record were in a list. In that case the merged record will not be included in any list
We are actually not doing anything special with lists when we merge catalogue records. The original record is kept and so the link is preserved. I am not sure what would be a correct fix here, neither if this is a bug. Marcel, Katrin, any thoughts about this?
I think the merge interface should include something to show which list(s) each of the merging records are included in and ask which of those lists the retained record should be in after the merge? It could default to assuming you'll only maintain the lists for the main record, but allow one to check boxes to include the other records' lists as well. That seems most consistent with the rest of the merge process, in which we start with the assumption of just maintaining the main record, but allow a lot of leeway to pick and choose which parts of which records are maintained.
(In reply to Jonathan Druart from comment #1) > We are actually not doing anything special with lists when we merge > catalogue records. The original record is kept and so the link is preserved. > I am not sure what would be a correct fix here, neither if this is a bug. > > Marcel, Katrin, any thoughts about this? Current behavior is not a bug. Just a logical consequence of merging.
Gotta have every possible opinion on it ;) Being in a list is more like items: while merging bibs, we don't ask you whether you want to move the items or throw them away, nor do we throw some of them away without mentioning it, we just move them to the kept record. Or, like being in an acq order.
(In reply to Phil Ringnalda from comment #4) > Gotta have every possible opinion on it ;) > > Being in a list is more like items: while merging bibs, we don't ask you > whether you want to move the items or throw them away, nor do we throw some > of them away without mentioning it, we just move them to the kept record. > > Or, like being in an acq order. I should clarify: a mechanism to select which lists to keep when merging records would be ideal. But in the absence of such a list, I'd rather see the final merged record kept in *all* lists that the pre-merged records were in. That seems more likely to be the desired outcome more often than simply keeping the lists from the main record. Further, in the cases where keeping all lists was not the desired outcome, it's relatively easy to correct. Re-adding a record to one or more lists from which it was silently dropped would be more difficult. In other words, I think there's a bug here, a merged record *should* be kept in all lists that previously contained the records that have been merged. And then there's room for an enhancement to make that behavior more flexible.
Current behaviour is an incomplete merge, as the resultant entry doesn't have the union of the initial entries' attributes and relations. See also bug 31181.
My first reaction was also to say that this is not a bug, but an enh. But I see where people are coming from: when we merge records, we move items, holds, acq orders... is there a reason to not move the lists? User expectation seems to be different and that makes me lean more towards a bug.
*** Bug 35550 has been marked as a duplicate of this bug. ***
Kicking this up to "normal" severity based on conversation with users.
I agree that this is an incomplete merge, and is a bug. It is definitely not a desired (and I doubt intended) result.
Wondering if this could get a second look.