Bug 27121 - Merge items
Summary: Merge items
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low new feature (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 21143 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-12-01 09:19 UTC by Séverine Queune
Modified: 2023-10-02 21:14 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Subscription items duplicates to merge (27.28 KB, image/png)
2021-01-18 08:07 UTC, Séverine Queune
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Séverine Queune 2020-12-01 09:19:20 UTC
As it exists for bibliographic records, it could be great if we could have a new feature to merge items (especially useful after merging records for exemple).
When we can face duplicate of items with both incomplete datas, instead of editing one and copy-paste the missing informations coming from the second item, we could have a form to check which datas coming from each items we want to keep after merging.
Comment 1 Katrin Fischer 2021-01-16 21:09:28 UTC
Hi Severine, do you have a use case in mind here? I am wondering about how this would work for physical items?
Comment 2 Séverine Queune 2021-01-18 08:06:03 UTC
Hi Katrin!

Here are two cases we've got at BULAC.

1/ A lot of our collections are still on card catalog only.
Some of my colleagues are working on cataloging them : they work on SUDOC (the French collective catalogue for Higher Educational and Research libraries) and each night, items and biblios enter Koha with unique identifiers linking to SUDOC ('ppn' for biblios and 'epn' for items).
Sometimes, for various reasons, some of the items were quickly and locally created in Koha, because it was important to have them there to follow a specific circuit (external loan for exhibition, etc.), and we regularly find duplicates.
The problem is that most of the case concerns our old and precious collections that have change of callnumber so we've got: 
- a local item with the new callnumber and informations about some physical peculiarities we noticed
- an item created in SUDOC with the old (and now wrong) callnumber and a unique 'epn'
The idea was to have a tool, like it exists for biblios, to select the 2 items and to check wich datas we want to keep from each items, in the present case all the datas of the local item + the epn for the SUDOC item.

2/ We had a problem during the initial loading of the datas in Koha for subscriptions.
The first load in March 2011 created items with callnumber and serial history only.
The second load in May 2011 creates duplicates with callnumber and all the datas about origin of the collection and the 'epn', but no serial history.
We still have about 1800 identified duplicates to manually merge...

I attach an exemple of a duplicates for subscription linked to items with, in green, the datas we want to keep from form each item.
Comment 3 Séverine Queune 2021-01-18 08:07:31 UTC
Created attachment 115232 [details]
Subscription items duplicates to merge
Comment 4 Katrin Fischer 2021-01-18 09:00:35 UTC
Hi Severine, 

thx for the summary, that makes a lot of sense! We should note that a merge tool needs to be aware of updating the links to subscriptions (serialitems) and to the acquisition order (aqorders_items). And possible course reserves (course_items).

Any others we could think of?

I think it might also be nice to log the merge in the cataloguing logs so there is still a way to figure out the merged itemnumbers.
Comment 5 Séverine Queune 2021-01-20 11:08:53 UTC
Good catch Cait !
Should we also udpate links to items_last_borrower ?

I didn't mention it previously, but I think it should be attach to a new user permission.
Comment 6 Katrin Fischer 2021-02-07 19:35:38 UTC
I think a new user permission makes sense.

I am not sure what to do about the last borrower in this case. Would it be possible that both items have a 'last borrower'?
Comment 7 Séverine Queune 2021-02-08 07:57:07 UTC
> I am not sure what to do about the last borrower in this case. Would it be
> possible that both items have a 'last borrower'?
Hum... In the different cases I imagine, I can't see how we could have 2 different borrowers, but maybe, if it finally happens, we could have a comparison between the 2 'created_on', or just keeping the most recent id ?
Comment 8 Katrin Fischer 2021-02-08 19:33:27 UTC
Sounds like we almost have a spec now - who will write it? :)
Comment 9 Katrin Fischer 2023-10-02 21:14:26 UTC
*** Bug 21143 has been marked as a duplicate of this bug. ***