Summary: | Merge items | ||
---|---|---|---|
Product: | Koha | Reporter: | Séverine Queune <severine.queune> |
Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | new feature | ||
Priority: | P5 - low | CC: | emjhet, m.de.rooy |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Attachments: | Subscription items duplicates to merge |
Description
Séverine Queune
2020-12-01 09:19:20 UTC
Hi Severine, do you have a use case in mind here? I am wondering about how this would work for physical items? 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. Created attachment 115232 [details]
Subscription items duplicates to merge
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. 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. 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'? > 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 ?
Sounds like we almost have a spec now - who will write it? :) |