Restore Buttons in Change History do not Appear to be Working Correctly

LegacyUser

Jeff Wiseman said: Some residences for 4 or 5 of my ancestors recently were changed to inappropriate values (they had all been "standardized" since they didn't have map pins). The street addresses had been removed and placed in the Reason for Change field, which of course will disappear the next time that item is touched.

In attempting to restore them without having to type everything in again, I found that selecting the Restore button did NOT restore the original value to the residence as expected. Instead, it just created a brand new residence entry with the current date.

As a result I had to then go through and remove all the duplicate residences.

Note that occasionally it would actually work like it used to, restoring the original data with its original change date and not adding a new entry with the current date. Also note that I occasionally got the red "Restore Failed" message and a partially greyed out screen (as though one off those modal windows was being turned on)

LegacyUser

Brett said: Jeff

'Yes', I have notice that too.
It seems to be happening a lot of late - ie. on the increase.

And, 'Yes', exactly why I want the "Map" 'Pins' to be "Removed" from 'Places' altogether in the "Person/Details" 'Tab' = They had 'Street Addresses'; but, "... they had all been "standardized" since they didn't have map pins ...".

I know that the Users/Patrons who make such "Changes" are well meaning; and, just feel/believe that the "Map" 'Pins' are required/needed for 'Places'; but, It has happened a number of time for my Ancestral lines; and, I do not have time to 'Educate' all such well meaning Users/Patrons - I just wish "FamilySearch" would just GET RID of those "Map" 'Pins' from 'Places' altogether in the "Person/Details" 'Tab'.

I have noticed that the "Restore" has been getting much more, either, non-operational; or, ineffective, when it comes to RESTORING a previous record, over time.

My preference is that the details as a WHOLE be restored - including that the details of the ORIGINAL ,'Time' and 'Date'; plus, User/Patron, were restored in the record, rather than mine; certainly, the current ,'Time' and 'Date'; plus, my "Contact Name", in the "ChangeLog" (and/or, "Reason Statement"); but, that does not happen - sad.

Wonder if other have noticed; and, whether "FamilySearch" is aware of such.

Brett

.

LegacyUser

Adrian Bruce said: OK, I admit it. I've been saying that you shouldn't need screen specific training if the User Interface was good enough. But how do you deal with someone who thinks that the Display and Standardised values must match so that there's a pin???

1. Training.... Sorry, you were right and I was wrong...

Mind you there's also:
2. Alter the pin handling (see a previous request. Somewhere in GetSat. Unless it's in a different space-time continuum.).

Currently the pin is shown if the place-name is standardised and the display name is equal to the standardised value.
If the display name has been standardised but is different from the standardised value (I call it "decorated") then the pin disappears. This nudges people into thinking that this case is wrong so they remove the "decoration", as per here, to get the pin back.

So either show the pin if the place-name is standardised, regardless of the display name.

Or remove the pin altogether.

LegacyUser

David Newton said: Or add a proper place details field and stop trying to shoehorn street addresses into the place field.