What does "Restore" mean when FamilySearch added a record? (Track Changes page)

LegacyUser

Justin Masters said: I'm looking at this page:
https://www.familysearch.org/tree/rel...



And I'm confused at what I'm seeing and what potential actions can be taken (and why).

From the bottom, I see parents added by FamilySearch... okay. But why does one say Restore and the other say current?.

Likewise, the two upper entries define biological relationships for each, but again, one shows "Current" and one shows a Restore button.

Uh... what am I restoring it TO, if FamilySearch is the first one to add that info/parent/relationship? And why is it limited to the father's side?

Hmm... as I'm typing this, I scroll upwards, toward the more recent changes, and I see someone had swapped out the father... so I presume that the Restore means to restore it back to that point/person, right?

LegacyUser

Tom Huber said: "Restore" in the change log, when clicked, will restore the entry from the time that entry was entered. In the above illustration, from April 14, 2012. The reason statement, if one was entered, will also be restored.

LegacyUser

Tom Huber said: You are restoring the information to the person whose change log you are looking at. The "current" (existing before you press "Restore") is replaced by the the original value that existed when it was originally entered (Apr 14 2012).

LegacyUser

Justin Masters said: Thanks Tom

LegacyUser

Jeff Wiseman said: Tom, in the case of another Restore problem I posted, the Restore will NOT restore residences, instead they just create brand new ones with the current date (and not the date of the original entry)
https://getsatisfaction.com/familysea...

I have no idea if the Restore button does this on other Custom type events or facts, but they may very well have the same problem.

LegacyUser

Justin Masters said: I can see that being the case if there were a desire to preserve an audit log, where all changes are seen, and never overwritten.

LegacyUser

David Newton said: Of course it won't restore a residence. All residences are mushed together in one gestalt entity in the system. See they're not unique events, so the system hasn't been programmed properly to tell them apart. Bad system design in other words.

LegacyUser

joe martel said: In this case you the conclusion that was changed is the Relationship's lineage type - and there is one for the father side, and one for the mother side. In this case it is being set to the father, and the mother, independently to "biological". The Restore will restore that specific (father or mother) relationship type.

This is a different situation than the multi-valued conclusions like Residence in Other Info. Each Residence conclusion is independent of the other to allow for multiple residences. There is a check that does not allow two or more Residences that have the exact same event information. When one Residence is deleted or changed it can be Restored independent of the other Residences on that Person (assuming it won't be a duplicates). All multivalued conclusions on the Person and Relationships follow this model. The UI groups those types together (all Residences show next to each other, all Alternate Names show next to each other), but they are each independent conclusion objects.

LegacyUser

Tom Huber said: Some of the events/facts in the "Other" section are lumped together. Eventually, this will cause problems when source tagging is enabled for those events/facts. One such is residence.

If you open a residence with Edit, and look at the history, the change log for all residences is listed. They are not limited to individual entries, but are, as Joe calls them, multi-valued conclusions. Thus, when a restore is made against a multi-valued conclusion, it is recreated, rather than overwriting the value.

According to someone from FamilySearch (I do not remember which representative) the easier route was taking during development. It was not a good choice to make, if full sourcing for all events and facts are to be eventually developed.