* Ancestry Synchronization now in Plugin Store

[Mark1834]

The RM-Ancestry sync plugin is now available in the Plugin Store as the Ancestry Synchronization plugin, and is fully backwards-compatible with FHUG versions.

The only significant change in function from the latest FHUG version is to give FH control of the list of “Changed” records in RM TreeShare. Results are much more consistent than leaving it to RM, making navigating TreeShare significantly easier.

In addition, there are minor presentation updates to both the user interface and Research Note reports. In particular, I have changed the Date: field from an ISO date time (yyyy-mm-dd hh:mm) to a simple date. The old version was a leftover from early FH7 revisions that did not sort Research Note dates correctly, but needed an extra Records Window customisation step to display correctly in later revisions. Now dates display fully with default settings, using your preferred date format.

Old FHUG versions will be deleted and the KB updated shortly.

[jelv]

Not that I will be doing this, but just an observation:

In the source you show how to add custom facts and attributes.

• If someone does this and you later release a new version they'd have to remember to reapply the changes
• Someone with multiple projects may not have the same customisation for each project

I wondered if you could store the additional facts & attributes in the ini file?

[jelv]

In https://pluginstore.family-historian.co ... ronization the final paragraph you could replace the link with https://fhug.org.uk/kb/kb-article/synch ... heading-10 to take the user correct section.

[Mark1834]

Ideally, I’d like to make the fact selection a lot simpler by reading the fact set files and presenting a list of facts for the user to select from.

However, the limited syncing offered by TreeShare makes modifying the list for an existing tree very tedious, as each individual affected would have to be updated manually.

It’s certainly worth considering storing the list in the project-specific options and alerting the user that it has changed, but they get that now first time they run a compare, with a long list of apparent changes.

It would be much easier if TreeShare had an automatic sync option, but FTM seem to have exclusivity on that, and they protect their database file from any type of updating (or even reading) outside FTM.

[Mark1834]

I intend updating the KB page and replacing much of it with a link to the plugin help, so the two pages will be complementary, not repetitive.

[jelv]

Mark,

Something that needs adding to the instructions:

If the only change made in FH (and hence RM) to an individual is to the Living flag, then TreeShare doesn't work. Although the individual is listed in the changed list, there's no arrows to enable the change to be pushed to Ancestry, all you can do is Show on Ancestry and Quick Edit the person.

I wonder if you may need a third section in the Update Research note to list the records that have to be directly edited on Ancestry after you've made the RM changes. They will be listed in the compare note as Living only changed.

I think the same may apply to sex, but I haven't tried that yet.

I'm having a 'discussion' with RM support about this deficiency, if I get anywhere I'll let you know.

[Mark1834]

Thanks for that John. "Living" changes are highlighted by the plugin, so I think the best option will be to add a warning note to the help file that TreeSync may not process these flags correctly, so it is the user's responsibility to check Ancestry entries to ensure living people privacy is properly respected. I'm wary of changing help files while CP investigate the count issue, as I suspect they may be related somehow, but it will be on the list!

If RM don't fix the omission, we can also display a warning message when the plugin sees a change to living status telling the user to check the change on Ancestry.

[jelv]

If RM don't fix the omission, we can also display a warning message when the plugin sees a change to living status telling the user to check the change on Ancestry.

I think you need to do this. My 'discussion' with RM is like banging my head against a brick wall. I've tried pointing out that a data protection complaint might arise if a living person is shown in a public Ancestry tree because RM failed to set the living status on Ancestry and they could be pointed to as being responsible!

[Mark1834]

Good luck with that one! It might actually warrant an additional warning message if the plugin default of excluding living people is changed -

Uploading personal data relating to living individuals without their explicit consent may be an offence under local data protection laws. By enabling this option, you confirm that you have read and understood this message.

[jelv]

Mark, could I suggest a small addition to the message box that pops up when you do an update to remind that the RM database should be closed.

[jelv]

Mark,

Having worked through the RootsMagic Update Guide, I've been rerunning the Update to make sure all the changes have been made correctly. Is this safe? If so is it worth recommending?

[Mark1834]

We can probably go one better than that - by using a similar technique to the Windows backup and restore plugin, it could actively check whether RM is open or not. I wouldn’t force-close it, but I’ll have a play with options.

On your other point, I tend to run a second compare at the end of the process just to check everything has gone through ok.

[jelv]

We can probably go one better than that - by using a similar technique to the Windows backup and restore plugin, it could actively check whether RM is open or not. I wouldn’t force-close it, but I’ll have a play with options.

Hmm... I tend in RM to go File, Close File. That means RM is still running but the database is closed.

The Windows title does contain the name of the open database, can you get at that?

[jelv]

On your other point, I tend to run a second compare at the end of the process just to check everything has gone through ok.

Is that before or after TreeShare? My thought is to make sure everything is correct in RM before starting on TreeShare using the original Update Guide. The update research note tells me what to do, whereas the compare just points out the differences.

[jelv]

I'm in the middle of a fairly big update. Having finished making the RM remaining changes I've just rerun the Compare and whilst it lists no individuals it has:

FH Individuals: 1785
RM Individuals: 1786
FH Families: 549
RM Families: 549

The Update report doesn't show who the extra RM individual is either.

[jelv]

Found him!

Code: Select all

select PersonID, count(*) count
from PersonTable
group by UniqueID
having count(*) > 1

did the trick!

Is that a check you could build in the the plugin update - it would detect when the RM merge has failed.

The reason for duplicate was that an individual had been recorded with the wrong gender which I changed in FH. The RM merge must assume that different gender cannot be the same person. Correct the wrong gender in RM, rerun the auto merge and then your update again and all is well.

[jelv]

You presumably do a select using the UniqueId. As you go through could you check that only returns one row?

[Mark1834]

Interesting - there’s quite a lot of code in the plugin already that deals with limitations in RM, so this is one more “feature” to address. Keep feeding in these observations, and I’ll have a play with my test dataset to check the best way to fix them (or highlight if unfixable automatically).

[jelv]

If the only change made in FH (and hence RM) to an individual is to the Living flag, then TreeShare doesn't work. Although the individual is listed in the changed list, there's no arrows to enable the change to be pushed to Ancestry, all you can do is Show on Ancestry and Quick Edit the person.
...
I think the same may apply to sex, but I haven't tried that yet.

The reason for duplicate was that an individual had been recorded with the wrong gender which I changed in FH. The RM merge must assume that different gender cannot be the same person. Correct the wrong gender in RM, rerun the auto merge and then your update again and all is well.

I've now processed that individual through TreeShare and am happy to report it worked correctly.

[jelv]

Having completed the update I have a better handle on the Living issue.

If the only change you have listed is the Living flag, it will be shown in TreeShare as a changed individual, but there is no way to do the update. You MUST use the Show on Ancestry option and check/amend.

All the cases where there was something else changed, after doing the updates and checking on Ancestry the Living status was correct.

[jelv]

Mark, A lot of the manual changes I am having to make in RM are where the name has changed (typically where I had something like Fred A Smith and I've found out what the A was for).

After the merge the updated name appears as an Alternate name in RM. You have to edit that to make the new name the primary and then you are able to delete the old name.

I could understand if you are reluctant to delete the old name in NameTable in case that breaks something, but I wondered if the update could set IsPrimary on the new name and unset it on the old name in NameTable? That would make it a lot quicker to work through the manual changes.

[Mark1834]

John, I'd love to be able to delete RM names from within FH, but it doesn't appear to be possible. RM uses a propriety format for name fields that is generally incompatible with external editors. Google RMNOCASE for the technical details, but much of it goes over my head!

A quick test with SQLite Expert Personal shows that it is possible to designate a different name as the primary name, so that amendment makes sense - make the primary names the same as in FH.

[Mark1834]

I don’t expect the pending release of RM9 to have any immediate implications for using the plugin, as the TreeShare facility is likely to be fully forwards-compatible, as it was from RM7 to RM8. Hopefully, RM won't do anything to break compatibility in other areas!

It will be some time before I test it directly, but as ever, raise any issues or questions here.

[MFriend]

Ok, Mark I'm an idiot when it comes to 'having' to use the latest version of software. I saw the blurb today for RM 9... so of course I had to buy it! Hopefully it won't be as buggy as RM 8 was when it came out.

Tomorrow I'm planning on using your plugin to upload a new private tree to ancestry using rm 9. Then I'll make a few changes to see how it goes. If it has any issues I'll let you know.

Thank you very much for the plugin by the way. I'm sure it was alot of work, but I appreciate it.

Matthew

[fhtess65]

Mark,

Apparently they've changed the file format again...will that make a difference?

I don’t expect the pending release of RM9 to have any immediate implications for using the plugin, as the TreeShare facility is likely to be fully forwards-compatible, as it was from RM7 to RM8. Hopefully, RM won't do anything to break compatibility in other areas!

It will be some time before I test it directly, but as ever, raise any issues or questions here.