Merge Parts

Bug #1099979 reported by Tim Spindler on 2013-01-15
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

It would be great to have a function that would let you merge two parts. For instance, we have Encyclopedia Britannica and one library entered it as v. 1 and another as vol. 1. It would be nice if there was a simple way to in the manage parts screen to select 2 parts and merge them and of course do all the work for moving copies to the appropriate new part.

summary: - Wishlist: Merge Parts
+ Merge Parts
Changed in evergreen:
importance: Undecided → Wishlist
status: New → Triaged
Tim Spindler (tspindler-cwmars) wrote :

Please see where development on this item has moved forward.

Dan Pearl (dpearl) wrote :

The parts ordering alluded to in the previous comment has been separated from this merge facility.

This is a proposed implementation of this facility, which seems to work for reasonably short lists of parts. When the list is long (>100 parts), there seems to be internal timeouts within Evergreen, and that produces a garbled display.;a=shortlog;h=refs/heads/user/dpearl/partmerge

Tim Spindler (tspindler-cwmars) wrote :

Please ignore my comment above (#1). I got mixed up about the launchpad bugs. Dan's is correct.

Tim Spindler (tspindler-cwmars) wrote :

Attached are the original functional specifications

Thomas Berezansky (tsbere) wrote :

I throw a different idea out, though it does have the issue of confusing interface until you reload the manage parts interface where two parts will be showing the same label, when in reality one of those two no longer exists.

With that SQL loaded into the database if you rename a part to the same name as a different part on the same record the two should automatically merge. Otherwise the rename goes through without merging.

This is based on code I originally wrote to "correct" parts at MVLC.

Kathy Lussier (klussier) on 2014-06-24
tags: added: pullrequest
Changed in evergreen:
milestone: none →
Tim Spindler (tspindler-cwmars) wrote :

We have looked at Tom's code and there are some nice things about it. It is elegant to execute and fewer clicks. However, we also found some issues with this approach and feel Dan's approach is still better.

Using Tom’s code we merged ‘v. 3’ with ‘v.3’. This is pretty basic and was easy. However when we merged multiple Parts for the DVD set Foyle’s War set 4, we had to edit at least six different Parts for ‘Disc 3: Bleak Midwinter’. This was very time consuming. This DVD set has 4 discs so that would be about 24 separate edits to Parts to fix the ones on this bib record. I also edited some Parts to merge ones for Time Magazine. I just did the few at the beginning that had numerical dates.

One more thing: Dan’s development has ‘dots’ to show where spaces are. This is helpful if there is a extra space at the end of the Part. Tom’s does not have that feature. We frequently have to fix parts becasue of typos where unintentional spaces were added.

Ben Shum (bshum) wrote :

Tested and I like it! Just some minor housekeeping for the proposed change.

Dan Pearl, can you update your commit and push again with a proper sign-off line for the work? Any other details you'd like to add at that time (LP#, etc.), please feel free. Setting status of this to "in progress" and assigning to original dev pending further work.

Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
status: Triaged → In Progress
Dan Pearl (dpearl) wrote :

I have resolved Ben's notes, above.

Ben Shum (bshum) wrote :

Thanks Dan, setting the status of this back to Confirmed. One more round of tests and I think we can get this pushed for 2.7 beta.

Changed in evergreen:
status: In Progress → Confirmed
assignee: Dan Pearl (dpearl) → nobody
Rogan Hamby (rogan-hamby) wrote :

Tested over the weekend and worked as I hoped. Signoff at user/rogan/lp1099979_partsmerge

Ben Shum (bshum) wrote :

Huzzah! Pushed to master for good times in 2.7 and onwards. This will be very helpful for managing parts. Thanks Dan! And Rogan too for testing!

Changed in evergreen:
status: Confirmed → Fix Committed
milestone: → 2.7.0-beta1
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers