What is the "new" way to restore a "deleted" individual?

LegacyUser

Stewart Millar said: I need to reverse a recent invalid merge - done by someone else.

Following the new merge process - when I access the deleted record - there is no facility to restore the "deleted" individual" (as there was in the past).

What is offered is a choice to "View Merge Details" . . .

Which then presents an option to "UnMerge"

Which resuts in the message - "Unable to unmerge these individuals"

How do I restore the "deleted" individual in this revised procedure?

Strangely - when dispaying the two records that I wish to unmerge/restore - the birth and death details for the (deleted) record I wish to restore are identical to the details in the surviving record . . . and as I have very recent printed FG Report I know that is not correct.

LegacyUser

Tom Huber said: I wonder if this is impacted by the operating system and or browser?

LegacyUser

Stewart Millar said: Using Windows 10 - I get the same resuly with Firefox and Chrome.

LegacyUser

Stewart Millar said: Anyone can have a look at this - the deleted individual to be restored is LV71-TL5 - despite what the display of the merge says (see my note above) - with identical birth and death details - the orginal records comparrison has them 11 years apart in age and from different counties of Wales.

LegacyUser

Jeff Wiseman said: This looks like an improvement!

there is no facility to restore the "deleted" individual" (as there was in the past)

This does not appear to be correct. If you look at the history on the surviving PID (GM34-7HN) you see:



There have been NO changes to the surviving PID since the merge, therefore IT SHOULD NOT BE POSSIBLE TO PERFORM A RESTORE ON THE DELETED PID! The only "fix" that should be allowed is an unmerge operation.

It appears that FS has now blocked that ability which never should have been allowed before. When people perform restores on deleted PIDs when they could simply be unmerged, the surviving PID never gets cleaned up properly, because, well, who cares? If you've restored the only PID that you were interested in, why should you be responsible for cleaning up PIDs that other people have scrambled because of carelessness?

Anyway, it looks like a totally appropriate improvement in the unmarking, delete restoring type handling of things.

Note however, the the inability to perform a correct unmerge may be a problem.

LegacyUser

Jeff Wiseman said: Have you tried performing the unmerge from the change history of the surviving PID (GM34-7HN)? That used to always work when it was available.

LegacyUser

Stewart Millar said: Undoubtedly a move in the right direction - except that executing the "Unmerge" button returns the message - "Unable to unmerge these individuals"

Why? - it does not say.

Using the "Unmerge" from the survivor or (proposed) deleted record gives the same message.

I do need some help to correct this invalid merge.

LegacyUser

Jeff Wiseman said: Ok, so it appears that the UNMERGE feature that used to always work has been broken.

If you were to slightly alter something trivial on the surviving PID, the unmerge button should disappear in the change log and the Restore button should reappear on the Deleted PID page. It might be useful to see if at least the "Restore" function still works.

LegacyUser

gasmodels said: Unmerge as far as I know was always done from the surviving PID. In this case there is an Unmerge link in the change log of the Surviving record as Jeff suggested above.
Restore is always done from the deleted record so if you wanted to restore you have to locate the delete record. Most simply go to the surviving record open changes and in the merge box choose the rhs record name. Click on it a person tab will open which you can use to get to the deleted record.

LegacyUser

Stewart Millar said: Thank you Jeff - making a small change to the surviving record triggered the removal of the "Unmerge" option . . . and allowed the "deleted" record to be restored.

So the problem is really to do with the "Unmerge" option refusing to work.

LegacyUser

Jeff Wiseman said: Terrific! So at least we have an obscure and VERY kludgy workaround until the recently BROKEN unmerge function gets fixed (when ever that might be).

The unmerge function was the only really decent way to fix bad merges when it was available. Now it is not available due to broken software so we have to go through the entire process of performing a Restore on the deleted PID and then removing everything from the original surviving PID that didn't belong there.

Note that when inappropriate Discussions are incorrectly merged over, and then the deleted PID is restored, it is currently impossible for anyone to remove those incorrect (and now DUPLICATED) discussions from the surviving PID without the help of Customer Service or the person who actually created them in the first place.

Also any changes made to the content of one of those discussions will immediately show up on the same discussion attached to the OTHER PID even though that discussion has absolutely nothing to do with one of the PIDs it is attached to.

We need the unmerge function working again so that we don't need to use these kinds of hacks.

LegacyUser

Jeff Wiseman said: gasmodels, that doesn't work. When an unmerge is possible, the "Restore" button on the deleted person's profile is REMOVED and replaced with a "View Merge Details" button which is used to allow you to view the previous merge in detail before finally choosing to unmerge it. It will not permit you to perform a restore operation at that point, which is exactly the behavior that you want.

Great Idea! Except the actual unmerge function itself is now broken and doesn't work--neither from the deleted person pages or the surviving persons change history log.

I guess that I should also mention here that attempting to perform the unmerge from the surviving PID change history does NOT bring up the new comparison window as when you select the "View Merge Details" button on the deleted PID details page. So depending on which way you approach that SAME EXACT merge, the unmerge function behaves differently (although at present they are BOTH broken)

LegacyUser

gasmodels said: Jeff, I completed a merge this morning and tested the unmerge to make sure it worked correctly. I had no problem it worked exactly like it should. I then remerged the records and continued to complete the merge of the the father. You can look at the change list of Jane Cannell 9SMR-SXW and see a merge, unmerge and another merge all completed this morning. As near as I can tell the system is working exactly as advertised. I did not encounter any issues. You have to do the unmerge from the surviving record.

LegacyUser

Stewart Millar said: It was my experience that started this issue - and at the time - yesterday - the "Unmerge" would not work from the surviving record - and I wonder if you noticed (gasmodels) - when the unmerge window shows comparing the two individuals - both had the same birth and death details of the surviving record - clearly not correct.

LegacyUser

Jeff Wiseman said: gasmodels,

You are correct, it is now working again and you CAN also initiate an Unmerge from the deleted PID. It appears that FS has removed the side by side comparison view that was inserted prior to the unmerge (and that view had at least 2 other issues with it as well--i.e., it wasn't providing the correct data, and only existed in one of the two places that an unmerge can be initiated from).

Now when you select the "View Merge Details" from the Deleted PID page, it just takes you back to the Unmerge button in the change history file for the surviving PID. Besides the fact it seems to be working now, the Unmerge behavior is identical whether you start initially within the change history for the surviving PID, or you start from the Deleted PID page using the "View Merge Details" button. It also nicely blocks anyone from performing a "Restore" on the deleted PID when an Unmerge is still possible.

It appears that they are trying to create a view showing the pre-merge PIDs side by side so you can see what things will look like when the Unmerge is completed. Another good idea by FS that unfortunately was broken when it was installed on the production site. I suspect that we may see that comparison page return once they fix it.

LegacyUser

joe martel said: So this is working as expected (like it used too)?

LegacyUser

gasmodels said: Joe, I never experienced an issue as near as I can tell it works correctly. I did several merges yesterday with no issues and in one case i did an unmerge to see if there was an issue. It worked as expected for me. I cannot confirm whether there was really an issue or not.

LegacyUser

Jeff Wiseman said: "Like it used to?" Yes and No. The Unmerge function appears to be working as it did before--that's a positive.

Regarding the "like it used to be" Restore function for a PID deleted via a merge: It was ALWAYS possible to do a Restore--even when an Unmerge was available and should have been used instead of the Restore. But now a person is PREVENTED from performing a "Restore" on a deleted PID if it is possible to recover it using the Unmerge method. However, this is a BIG positive.

So functionally, we are just fine right now (and a bit better than before).

It is obvious that the engineers are wanting to introduce some screens that will display exactly what the result of an Unmerge will be just prior to initiating the Unmerge action. Sounds like a great idea, but they released it into the production system 'way too soon, and obviously with little or no testing.

Again, we are good for now.

LegacyUser

Jeff Wiseman said: gasmodels, I'm pretty sure that FS yanked the broken feature just prior to your testing the other day. The timing was right at the point when your note appeared here on the discussion. That is why you didn't see it.