Show more of the person page of a person deleted by merge.

LegacyUser

Anita Wight said: When you view the person page of a person deleted by merge, it would be nice to be able to see the family relationships, and not just the "top" part of the person page where it shows the vitals. Sometimes I have wanted to un-merge just to see what it looked like before the merge.

LegacyUser

Jeff Wiseman said: I agree. seeing the source list and full change log would also help.

I've not actually tried this, but if you restore a person that was deleted via a merge (or any other way for that matter), can you turn around and directly delete them again?

The restored record would have all the previous changes by OTHER people still in place. Normally, if this is the case, you wouldn't be able to delete that person except via a merge.

LegacyUser

Brett said: Anita

I totally agree.

I have always been thinking and wanting that, rather than having to look at the "ChangeLog".

Brett

.

LegacyUser

Tom Huber said: We should not have to restore a merge-deleted record to se all of it. We should be able to see everything, including ordinance data.

I have never understood why FamilySearch has not displayed the entire record.

Restoring a record, realizing that the merge was merited, and then the only thing that we can do is to merge it again???

What is that going to do now that we have a new merge system? In the past, most of the time we could go ahead with a relatively clean merge, but now?

LegacyUser

gasmodels said: What I do is not restore in the active system but go to beta.familysearch.org and look for the ID. If it was a recent merge it is likely to show unmerged in Beta and therefore you can see all of the information. If it is an older merge, you can do a restore in Beta, look at the record and just leave it not having to worry because beta is just a "play" environment. This allows me to see what I would like to better make a determination of whether it is an incorrect merge or not without making any changes in the active system. I usually use my Edge browser for Beta and Chrome or Firefox for the active system. So it is reasonably easy to change browser and see what I would like.

I do agree it would be much nicer to be able to view more information in the active system.

LegacyUser

Paul said: I regularly have to restore a person who has been merged / "deleted". (BTW - why does FamilySearch apply the latter term to both merged IDs and ones I really have deleted?) I restore the record with a comment like, "Temporarily restored to check validity of merge" then, if satisfied another user has taken the correct action, immediately delete / merge it again

So, yes, I would also find the ability to see more of the deleted person's profile most useful, to save this otherwise unnecessary work.

LegacyUser

Anita Wight said: Good idea

LegacyUser

Anita Wight said: good idea, thanks!

LegacyUser

Jeff Wiseman said:

(BTW - why does FamilySearch apply the latter term to both merged IDs and ones I really have deleted?)

This is another example of probably inappropriate use of terminology. When a PID is "deleted" (either via a merge or a direct deletion of the PID), it really is NOT "DELETED". It is archived. I.e., it is simply disconnected from the mainstream of the tool where both patrons as well as search tools and hint engines, etc. can no long see them.

A PID is forever!

Once you create a record, it will exist forever either in the main tree, or as an archived record. That PID number will never be reassigned because it is used by the archived record for identification in the system. You can not "delete" it or "purge" it from the system in any way. It is simply set aside from all the normal operations of the system.

LegacyUser

Jeff Wiseman said: BTW, as a reminder, you should ALWAYS first check to see if you can perform an "Unmerge" before you proceed with a "Restore" on the merged-away PID. Although it seems rare that you can do this, if you can, it is far more unlikely to lose or miss data adjustments during the cleanup afterwards.

LegacyUser

Ken G Moyer said: That's the reason I use two monitors. Original on left on it's own tab and survivor on the right. Nowadays the cost of a second monitor is not a big problem and Win 10 handles them very well

LegacyUser

Adrian Bruce said: Jeff, even as a born-again pedant, I don't have any problem with describing such PIDs as deleted. It's quite normal - to me - that "deleting" a record actually does a logical-deletion rather than a physical-record-deletion. (If that terminology makes sense).

What does get awkward (to me) is using the same term for "merge-deleted" as for "delete-deleted" - the "use cases" there are so different.

LegacyUser

Jeff Wiseman said: The problem here is that the deleted record does not show all of the data associated with it. So regardless of what hardware were might have to view it, FS just does not display all of the data associated with the deleted record.

LegacyUser

Jeff Wiseman said: Understood. But in both cases, the end result is still exactly the same, so why wouldn't you use the same term to describe it? The PID "record" has only been moved into a different state. It has not been physically eliminated.

If you look up the word "delete" you will see that it's main context is traditionally in the physical world, e.g., deleting physical files or erasing text on a paper or from a computer entry. The process of restoring, undeleting, or "un-erasing" applies to virtual entities.

The original meaning of the term is set in the context of a physical world. The minute you add the use of that term in a virtual world (as is being done here), it becomes ambiguous unless the context of its use is also identified with it. In other words, you have to state EXACTLY what is being deleted since you cannot longer infer that the item being deleted is a physical item.

If you "delete" a person file in the FT, it is removed from the FT (a virtual removal) but NOT removed from the FS computer system (a physical removal).

This built-in ambiguity of how the term is used in FS (i.e., without identifying the context that it is used in) is the very reason that when you tell someone who has just started working in the system that "when you delete a person PID record, it really isn't actually deleted", they tend to be surprised. Their assumption is typically that the term is being used in a physical sense.

That's why in computer work we frequently have to use the term PURGE to represent true deletion.

LegacyUser

Tom Huber said: Uh, I'm not sure I agree that deleted-deleted and merge-deleted results are the same. The "deleted-deleted" should be referring to a user-deleted record vs a merge-deleted record.

The user-deleted record does not have deletion path that can be followed to a surviving record, whereas
A merge-deleted record does have a deletion path to follow to the surviving record.

And yes, the record itself is preserved, even though it is no longer "find-able" via the Find search routine. It is "hidden" from view and can be restored (in both cases).

But I do agree that the use of the word delete is ambiguous. In its place, "removed from view" and "hidden" are better terms.

LegacyUser

Jeff Wiseman said: As I've suggested in the past, the word "archive" may be more suitable than the instruction to "delete". Everyone tends to think that archiving something means to put it in some safe storage location elsewhere.

By the way, a habit I got into a couple of years back was that when I created a link between an Ancestral Quest record and one in FS, I would copy the FS PID and paste it into the notes for that person in AQ with the tag FSID: (FamilySearch Identification number). This gave me the ability to go back and recover PIDs that people had been directly deleting. I still do this perhaps mainly out of habit, but when a merge occurs and AQ tracks it, it is just a bit more information to help me find those deleted records.