New change log.

LegacyUser

C Hodgins said: New change log. If a merge is the latest item in the list, there is an option to Restore. It used to say Unmerge. I know that restoring a merged record is very different from unmerging a recent merge. Should the change log be saying unmerge instead of restore? Now it is confusing.

LegacyUser

Roy F Hunt said: When clicking on "See all changes" you are now taken to the pedigree rather than to the change log.

LegacyUser

Tom Huber said: Is that the "Show All" link at the bottom of the last few changes for a person's profile, or somewhere else.

If it is the Show All link, then I'm not having a problem. Chrome on Windows 10.

LegacyUser

Tom Huber said: I wonder if this has to do with changes that also impacted other person's made during the merge. If one of those was changed, then it is possible that the unmerge would not work correctly and Restore was used instead.

I think more examination needs to be done, since some items are automatically moved to the surviving record and an unmerge should restore the merged record and return the surviving record to its state just before a merge. That could impact the Family Section of the profile.

LegacyUser

Merlin R Kitchen said: As I understand, the merge can be unmerged only is other changes are not made after the merge. As soon as something else is done to the merged record, such as adding a source or changing some vital data, they can no longer be unmerged and the unmerge option goes away; the only option you then have is to "restore" the person page of the one that was archived during the merge.

LegacyUser

Jeff Wiseman said: Try going into one of the vitals and select the Show All link there. This still takes me to the pedigree

LegacyUser

joe martel said: When I click on the Show All Changes at the bottom in this screen shot it takes me to the ChangeLog filtered on Birth. So it's working for me:

LegacyUser

Tom Huber said: Jeff, what is the browser and operating system you are using. I'm not seeing the problem with either Chrome or Firefox on a Windows 10 computer.

LegacyUser

Tom Huber said: However, that is from the show all on the profile page under Latest Changes.

When I checked with a See All Changes on Birth (using Pieter Claesen 9312-XFX, the pedigree view opened instead. Definitely a Bug using Chrome on Windows 10. Firefox on Windows 10 has the same issue with See All Changes from the Birth Edit Window.

This appears to be a problem with each of the Edit windows in Vitals and Other information. Again, it impacts both Firefox and Chrome on a Windows 10 computer. It also impacts the Couple Relationship modal window's See All Changes (at the bottom of the window -- opens to the pedigree view.

I have not checked each edit window, but I suspect the problem impacts all of them.

LegacyUser

Tom Huber said: Nope, it isn't related to a merge. I just checked a profile where no merges had ever taken place and the problem persists with both Firefox and Chrome on a Windows 10 computer, using "See all changes" from an edit window.

LegacyUser

Tom Huber said: I've tested both Firefox and Chrome on a Windows 10 laptop computer and in all instances, whenever "See All Changes" is selected from an edit screen, like the one you illustrated in this reply,, the system opens the pedigree view, not the filtered change log.

LegacyUser

Jeff Wiseman said: I just tested both Firefox 76.0.1 and Safari 12.1.2 on macOS Sierra 10.12.6 and it is the same as Tom's experience. It doesn't matter what vital you edit and on any person I tested it on, It ALWAYS takes me to the pedigree page for the person that it was vectored from. Also, this was both before and after deleting all cookies and rebooting the system.

LegacyUser

Jeff Wiseman said: C Hodgins,

Sorry about your original topic being hijacked. There are certainly a lot of things going wrong with these things presently.

Regarding your comment and question: Absolutely YES! The use of the word "Restore" now appears to imply exactly the opposite of what it actually does!

When you do a "Restore" on a PID deleted via a merge, only that PID is restored to its pre-merge state. A change history log is all of the changes relative to a single PID. So in the case of the surviving PID from a merge, having a "Restore" button in that specific PID's change history implies that you are only restoring that surviving PID to its pre-merge state! I.e., the other PID that was deleted via the merge will remain deleted.

The term "Unmerge" (just like "Merge") by definition ALWAYS refers to two different PIDs, so if you want to undo the effects of the merge on BOTH of those PIDs, it would be an "Unmerge" function and NOT a "Restore" function which by context would only operate on a single PID (i.e., the PID whose change history contains the button).

This kind of inconsistency and ambiguity in the terminology is a common problem in FS.

LegacyUser

Pioneer42 said: exactly C Hodgins, but nobody will do anything about it. They like the NEW look, its they dont care about the aint broke dont fix issue. All they had to do with the last one was add a sort feature, everything else in there is useless. It's always and only ever been about being used for correction use only. Merging only one of the biggest issues EVER on FS. But what do I know, I only put in 6000+ hours to resolve half of it myself...The end is not yet but by and by as Moses stated in the book of Revalation by John, applies here.

LegacyUser

Gordon Collett said: So apparently something is very unstable in the system somewhere or different users are accessing different version of the website because I checked just now and the See All Changes links in the edit boxes all go correctly to the change log with the proper filter applied. This is on macOS Catalina 10.15.4 with Safari 13.1 and with Firefox 76.0.1.

LegacyUser

Jeff Wiseman said: Gordon, if I remember correctly Joe also uses macOS Catalina, so his configuration is likely similar to yours and both of you aren't seeing a problem. This might be relevant.

LegacyUser

Pioneer42 said: Jeff Wiseman, Except you are partly mistaken, an unmerge will not undo both, you still have to go into the other individual and choose unmerge there too if that spouse was also merged. How is that inconsistent? Meaning it only puts it (he or she) back to the state pre-merge. It has to be this way or otherwise one of the people in the merge can possibly be removed unintentionally because one of them was probably the correct individual that matched the person you merged it to, that got corrupted by another merge far back with the spouse (which is probably the one that doesn't belong to that particular person, there is other reasons too to know, its many ifs). The other issue is that of people dont look and just push over based on name only, its insane. And that is why you have to go into the other person and unmerge or restore them too if they are not the same individual or if the unmerge is unavailable do to a change in the field after merge*.
I never had a problem with this, nothing has changed there. The main issue that the old system had a error, in my judgement is that after you merged lets say, you went in and changed a vital field (like a b-day) and then you went back into the changes log, and then the green merge no longer has the unmerge capability. So now your are forced to go into restore to do it. Problem with that though...*IS THAT ANYTHING THAT WAS ADDED IN THAT MERGE HAS BEEN BROUGHT OVER AND NOW IT REQUIRES YOU TO REMOVE IT ALL MANUALLY INCLUDING SOURCES, WHEREAS A UNMERGE WOULD TAKE IT ALL BACK TO THE INDIVIDUAL! What I have always hated about this program. Anyways I see what you mean, it probably should state restore to pre-merge, instead of restore. But if you don't understand this, probably shouldn't be using this program. Or at least you should be very careful in merging, which probably should be done now by a arbitration group, as there is so many foul ups!

LegacyUser

Jeff Wiseman said: Yea, and on an additional note, the term "Unmerge" has been correctly used for a couple of years now. Why change it to something that is more illogical in that application while calling it an "improvement"?

Also the "Restore" function on a deleted PID is really doing nothing more than unarchiving the PID. So the Restore will "Undelete" the PID regardless of whether it was deleted directly via a user or indirectly via a merge.

LegacyUser

Pioneer42 said: There is no difference between restoring and unmerging. You are confusing yourself. Either a person has been merged into your person or you have merged your person into somebody else. Restore and unmerging had a similar consequence. It put them back to pre-merge state right before the merge. The problem is (the difference between the too) is that IF YOU MADE A CHANGE AFTER THE MERGE TO THE PERSON YOU MERGED INTO (LIKE A BDAY), RESTORE BECOMES THE ONLY CAPABILITY NOW. Why? Because the unmerge button is now gone (hate it when this happens), and now your only option is to go into the person that was merged and choose RESTORE. Now what this means is that that person will go back to the way it was pre-merge. But where the issue is incredibly painful is that if it was a huge person of data that was merged to another, it would bring over all the sources into the other person it was merged too. So you would have to go in and MANUALLY REMOVE ALL OF THAT DATA FROM THE PERSON THAT HE OR SHE WAS MERGED TO. A real Pain in the you know what. If that doesn't make sense I don't know how else to explain it.

LegacyUser

Pioneer42 said: but now none of this matters and the church has decided to go about it the hard way via restore. It just takes longer is all, but a real pain.

LegacyUser

Gordon Collett said: It might be a difference between Sierra and Catalina. But it seems strange that the operating system would have enough influence on a browser to make the browser take a command to a completely different web page. That we are both using the same version of Firefox and getting different results is what make me think there are currently different versions of the program on different servers and the results you get depend on what server you are connected to. But then I really don't know much about how networks work.

LegacyUser

gasmodels said: The issue you are concerned about is that once changes where made you cannot just unmerge anymore because which record does the change apply to. When you merge there are two records both have information attached say sources, birth information etc. After you merge if someone edits the birth date or adds a source, it is not clear which of the record that change belongs to so the system may attribute the source to both record and you have to make corrections after the restore. Does not seem unreasonable to me and I do a lot or restoring of incorrect merges.

LegacyUser

Jeff Wiseman said: Yea, I agree. It's just the engineer in me looking for the common denominator :-)

LegacyUser

joe martel said: Correct me if I'm wrong, but I don't think there are new bugs regarding Merge/UnMerge/Restore.

1. You can Merge two PIDs. One is the survivor and one is deleted. That deleted Person nolonger shows connected to the tree, nor is served up in Find Person.
2. If there are no subsequent changes to the Survivor you can UnMerge and the two PIDs are restored to their state that existed right before the Merge.
3. If there are changes to the Survivor then you can Restore the deleted Person.

I don't see that this has been changed or broken with the new ChangeLog. If you think it has, screen shots of the problem would help diagnose any issue.

LegacyUser

Jeff Wiseman said: Pioneer42,
(Gee, I wonder where that name came from :-)

Unless I'm missing something, the function to unmerge the pair of PIDs doesn't appear to have changed. C Hodgins' observation is that they DID change the name on the Unmerge button in an inappropriate way.

There is no difference between restoring and unmerging...
Restore and unmerging had a similar consequence...

I am pretty sure that this is not the case. Whenever an Unmerge was/is possible, running that function fixes all the damage done by an incorrect merge by restoring BOTH PIDs and all of their attachments that were involved in the merge back to their pre-merge state (with a few odd design quirks).

Regardless of whether an Unmerge is available or not, it used to be (up until some time in the last few weeks) that you could ALWAYS perform a Restore on any Deleted PID (even those that were not deleted due to a merge). But doing so will only restore ONE of the PIDs (i.e., the deleted one) to it's pre-merge/pre-deleted state. In other words, it would always do only HALF of what an Unmerge would do.

Unfortunately though, people would frequently perform a Restore on the deleted PID when it was actually possible to do an Unmerge. The Unmerge would fix both PIDs where the Restore only fixed one. Then recently FS greatly improved that by changing the Restore function slightly. Now, if you are looking at a deleted PID, unlike before, if an unmerge is possible, the system will NOT allow you to perform a Restore on it. Instead, it routes you over to the Unmerge area. If an Unmerge is not possible, then you can perform a Restore on the deleted PID just as before.

A Restore on a PID deleted through a merge will do no more than HALF of what an Unmerge will do. That is why using the term "Restore" on the button that initiates an Unmerge makes no sense at all.

LegacyUser

Jeff Wiseman said: Joe,
Functionally, it has not broken. It is just that NOW in order to perform an "Unmerge", you have to push a button labeled "Restore" (which is a totally inappropriate name for that button considering what it actually does).

This is part of the initial confusion on the log pages that C Hodgins raised in his original post on this topic

LegacyUser

Jeff Wiseman said: My beef is that when you merge PID A into PID B, A is deleted and B survives.

If I now go into the change log for the surviving B and select something called “Restore”, that “Restore” will be intuitively applied only to PID B and will leave PID A in the deleted state.

Obviously this is not only undesirable, but it is ALSO not how the system works.

You don’t push a “Restore” button in order to start an Unmerge operation. You push an “Unmerge” button to initiate an Unmerge the way it has been done for years now.

Having a “Restore” button next to the merge history in a Change history log is not appropriate and adds more confusion to an operation that is already confusing enough for many folks.

Restore and Unmerge are not the same thing. Call a Spade a Spade.

LegacyUser

joe martel said: Jeff, Can you provide a PID? A Restore is different than an UnMerge and I need to see an example where it is confused.

LegacyUser

gasmodels said: Joe there is no UnMerge anymore. If you merge two records A into B and make no changes then you can go to the change log of B and see a "Restore" on the right hand side in the general area where UnMerge used to be.
Now if C had earlier been merged into be you can look at the change log for B find the merge and click on the name for C and the person page for the deleted record will pop-up if you go to the deleted person page there is a Restore on that person page to "recover" that record. I will not do anything to B except to remove the information associated with C and some may be retained because of changes after the C-B merge - this is exactly like the old change log.

I agree nothing has changed but now there are two different restores the sort of do different things. One separates recently merged records to their pre-merge condition and the other extracts a previously merged record but does not return the situation to exactly the condition before the merge. Hope that helps.

Margaret Mylchararne KZ56-J2Y is a record I just merged and you can see the "RESTORE" to undo the merge.

LegacyUser

Jeff Wiseman said: Joe, see if this helps,

I merged my Test Joanna Smith GQKR-SXH into Test Johnny Smith G9BR-NFM. Going to Johnny's change history log you get this:



As you can see, the "Unmerge" button of the past has been changed to "Restore". However, if you select it, it will return BOTH PIDs back to their pre-merge state (i.e., it will Unmerge them)

If you go to the deleted PID, You will find the "View Merge Details" button. Selecting it just returns you to the first image above where you can Unmerge them using the incorrectly labeled "Restore" button:



(By the way, when you do this, why does the system take you to the merge information in the surviving PID and not in the deleted PID? The information is in both places, but it is displayed from the perspective of the Deleted PID in the change history log of the Deleted PID and not the surviving PID log as it works right now)

If you now add an event to the surviving PID and then look at its change history log, you get the following:



As you can see, because the added event now prevents an Unmerge, the Unmerge button named "Restore" has been removed. Now going back to the deleted PID you can see that the ability to Restore that SINGLE deleted PID to its pre-merge state is now possible via the "Restore Person" button.

If you now perform the Restore on the deleted PID, it will undelete the PID and will not affect anything on the surviving PID. You now must manually clean it up and deal with the added event (i.e., which PID does it now belong in?).



Anyway, with respect to merges, we have two totally different behaviors using buttons labeled "Restore" now that we didn't have before.

LegacyUser

Gordon Collett said:

There is no longer any Unmerge command.

The concerns and complaints are due to a change in definitions.

In the old change log:

Immediately after a merge, Unmerge would be visible on the Change Log for both people. Clicking it would undo the merge and restore both people to their premerge state.

If any actions were done on the surviving person, the Unmerge would vanish and I think, correct me if I am wrong, would be replaced with the term Restore. Clicking Restore would take the deleted person back to that person's premerge state and would remove some information (primarily temple ordinances and, I think, Memories) from the surviving person but not very much.

In the new change log:

Immediately after a merge, Restore is visible on the Change Log for both people as the top entry. Clicking it would undo the merge and restore both people to their premerge state.

If any actions are done on the surviving person, the Restore vanishes from the surviving person and nothing can be done to reverse the effects of the merge other than just standard editing of the person.

However, going to the deleted individual's detail page or change log, one finds Restore links that restores the deleted individual to the premerge state and removes some information (primarily temple ordinances and, I think, Memories) from the surviving person but not very much.

So yes, undoing a merge and doing a restore are different actions and used to be covered by two different words. Now they are still two different actions but are covered by just one word.