Identification for both duplicates in Reason statement box, when Merging

LegacyUser

EvaLynn Holt said: When I merge a set of duplicates, I have always just highlighted the name and pid number and copied it to the reason statement box, and pasted it. Then I do the same for the duplicate person. That way IN CASE I HAVE MADE A MISTAKE AND HAVE TO UNDO THE MERGE, both pid numbers are kept, and the UNDO is simple. In the new version of the merge process, I can't copy and paste. (Before the number was next to the name, and highlighting and copying it didn't trigger a hyperlink- and both were available at the top of the page.) Could we please make them both available again on the same page as the reason statement box, or automatically add them to the reason statement box, so we don't have to take the time to add them.- The latter would actually be my choice - that would be fantastic:) Thank you--- you are amazing to do all that you do!!

LegacyUser

Jeff Wiseman said: This is one of the things that the change history file is SUPPOSED to be used for.

If the merge was a mistake, go into the change history log for the surviving PID and find the place where the merge was performed. If there is an "Unmerge" button showing, then click on it and you are completely back to where you were EXACTLY.

Unfortunately, that "Unmerge" button is almost never there. If anything was touched on the surviving PID after the merge (even adding a space in the name on the PID) the Unmerge is not provided since it can't tell how the change you made fits in with the TWO PIDs that were originally merged.

In this case you just go to the place in the change history log where the merge was performed and find the person that was deleted by the merge. Clicking on their name takes you to that deleted record in the permanent archives. From there just click on the Restore button and (we've been told) everything will be restored on that deleted record to exactly as it was right before the merge.You will now need to go to the surviving PID and manually remove all of the sources, attachments, and reverse any attribute value changes that were made by the merge.

No need to copy the PIDs into a field that wasn't intended for that use, and will just get shoved down into the history stack out of sight the first time someone makes another change to it.

LegacyUser

Jordi Kloosterboer said: You just have to click on the PID and it is in your clipboard.

LegacyUser

Paul said: EvaLynn

I have taken to the same practice you are talking about. The change log does not always present the clearest of pictures, so mentioning the IDs concerned can save a lot of confusion.

The other point where this applies is to Notes & Discussions. When these are carried over in a merge they can present a lot of confusion. For example, if I put Discussion items against two IDs - both with the same title - it creates a lot of confusion when you return to the surviving ID a couple of months later. If you have not deleted one of these items (at the time of the merge) you will have (say) two "Identity of William Brown" items and - without ID references - will not easily identify which is applicable to the surviving ID and which refers to the one that has been deleted!

Yes, it really is a good idea to reference the ID in the merging process and at any other time you think there might be the prospect of a future merge. Unfortunately, this might not be considered important enough for FamilySearch to create an enhanced feature to help deal with the issue, so we'll probably have to continue with typing the ID references ourselves, for now.

LegacyUser

Juli said: Mystery meat on steroids?

LegacyUser

Jordi Kloosterboer said:

LegacyUser

Jordi Kloosterboer said: Jili, I don't know what you mean lol

LegacyUser

Jeff Wiseman said: Paul,

If one of the PIDs was incorrectly merged before and the deleted PID had a discussion, That discussion is now on the wrong PID. You cannot do a thing about it. You cannot delete it regardless of how ridiculous it might be.

Discussions were a design that was very misguided. At present, they are not used for much more than read only Notes. They are just another way to dilute the use of Notes in the system, and they are normally used for functions that they were never intended for.

Typically, people just use them to broadcast their own personal view about the record to everyone that visits it in a way that other cannot change or remove. It is used as a billboard. When merges occur incorrectly, discussions that do not apply will be transferred to the new incorrect PID where nobody else can remove them. Even if somebody wants to fix an incorrect merge by doing a restore on the deleted PID, the discussion is permanently attached to the wrong PID.

Unless the person who created it sometime in the past happens to come across the bad merge and try to fix it themselves. Then they are the only one that can remove the inappropriate Discussion.

The discussion feature should be removed from the system and the messages feature (i.e., the REAL discussion capability) should be enhanced.

There is only ONE thing that I have found it can be useful for. Occasionally people want to keep merging the same two PIDs incorrectly. After undoing this a couple of times I have done this: In PID XX, I create a discussion saying something like:

"This discussion belongs to PID XX which should NOT be merged with PID YY because (place reason here)"

Then for PID YY, I create a similar discussion, e.g.:

"This discussion belongs to PID YY which should NOT be merged with PID XX because (place reason here)"

Now if the perpetrator insists on doing the merge again, along with their personal ID they will end up with 2 discussions on the surviving PID proving the fact that they should NOT have done what they did. Furthermore, they will not be able to remove either of the discussions! So the discussion showing that the merge was screwed up now permanently remain with the screwed up merge. I am the only one who can fix it.

One of the other nasty side effects of the ill-begotten Discussions feature is that when multiple merges occur, those discussions will spread all over the place, and the creator of them won't be able to even find them to fix the mess. In fact, they don't even know it has happened (unless, of course, they have a watch on the initial PID).

People should NOT be using discussions as they are not effective as a collaboration tool and are idiosyncratic in their behavior. I could write an entire essay on this (just do a search in the forum on the word "Discussion"), but since it would likely change nothing, I will leave it at that.

Note that all the people who really want to KEEP this feature are all using it for something it was never intended for. They want to put data in the tree that cannot be altered (sort of like wanting control of their own "tree"). That is a forced, one-way function that is about as FAR from the collaboration needed in a shared tree as you can get. For some examples as well as some talk on Merges with Discussions:
https://getsatisfaction.com/familysea...

LegacyUser

Paul said: Yes, I was thinking more of Discussion items raised - hence able to be deleted - by me. You have highlighted the downside of other users not being able to delete these items. It's so true what you say - read the comments in a Discussions item after a merge and you think, "What ever is that all about?" before realising the comments probably only made any sense when placed against the now deleted ID.

Lately, I have been reluctant to use Discussions and usually only do so if I am desperate keep a highly important fact / statement remain on the page. Otherwise, Notes is my preferred option, as they can be removed by others if circumstances make them no longer relevant - possibly after my demise!

Thanks again for very useful comments.

LegacyUser

Jeff Wiseman said: Yes, Several people will create discussions, but they do it so that they DON't HAVE TO DISCUSS anything. It is rare for somebody to collaborate by adding to the discussion. Personally I have NEVER seen any of these types of responses to discussions.

And although Notes for a person record are available in all other genealogy systems (they are even supported in the GEDCOM standard), nobody else has discussions implemented as notes in the way FS does. That makes those parts of Family Search record proprietary and difficult to move to any other platforms.

I also refuse to use Discussions for "Discussions", as they just don't work for the purpose they were designed for.

LegacyUser

EvaLynn Holt said: Thanks for your help. I will just write down one ID (to be typed manually) and copy the other and carry on about my business. Sorry to cause a commotion.

LegacyUser

Jeff Wiseman said: No need to apologize. It was a legitimate suggestion (especially since the capability was there in the old merge but has now been REMOVED from the merge. There are just lots of folks here passionate about having a well functioning system :-)

However, I do apologize for your topic getting hijacked! The intended takeaways for your specific suggestion here was:

1. Whether or not FS decides to implement your suggestion, and in spite of the cryptic nature of the change history logs, finding the links/PIDs to the PIDs involved in the merge has ALWAYS been fairly easy since the merge change history is enclosed in a big green box.

2. You cannot guarantee that anything you put in the "Reason statement" will be there when you come back as any further changes by other will push yours farther down the stack in the change history. So in this case you will STILL have to go into the change history log to find them anyway.

So regardless of what FS does about your request, you will almost always have to go to the history log anyway. Using the links from item "1" just seems to be a lot more reliable IMHO.

LegacyUser

Carolyn Wheeler said: In the past I have always copied the name and PID of each merged person and pasted it into the reason statement box. Now doing that is exceedingly difficult, and I sure don't want to have to handwrite names and PIDs to manually enter - that is about a million steps backward. But I have found a work around. It's not great, but it does work - until they fix the problem!!!!

This is how I copy/paste names and PIDs in the new format. Hope it makes sense.

First I select the name and PID of the desired person at the same time. When I do that it brings up a card for that individual. In this case I selected the name and PID on the left (pink) column. The card it generates is on the right, overshadowing the green column.


Then I follow the same process and select the name and PID in the card on the right. This time when the card name and PID are selected I copy it and use that to paste into the reason statement box.


It's a weird work around, but it is better than handwriting names/PIDs and manually entering them.

I hope this makes sense, and I do hope that the engineers fix this problem soon - as in VERY soon!!!

LegacyUser

Juli said: Non-standard, unlabeled functionality: mystery meat navigation. Apple used to be the prime offender, but it's everyone, now, and FamilySearch appears to have outdone them all with its PIDs that look like plain text but are actually "copy" buttons: mystery meat navigation on steroids.

LegacyUser

Jeff Wiseman said: "Mystery Meat" that is a lot worse than Spam :-)

LegacyUser

Jordi Kloosterboer said: oh haha makes sense lol

LegacyUser

EvaLynn Holt said: Of all the comments on my initial comment, this one feels like someone knows what I am saying, and has a sympathetic concern for me. Thanks so much. I will use your suggestion and I will also hope that the engineers can feel our pain and help us out. Thank you so much for commenting and going to the effort to illustrate your solution so that i can "get it". Thanks again.

LegacyUser

EvaLynn Holt said: Thank you. I have always used the history of changes, it was just nice to have both pids there together. I have only had to unmerge once in hundreds of merges, it was just kind of a safety net for me. I will get it figured out, but I do thank you for your comments and for your acknowledgement of my concern.