Family Historian User Group

I am trying to find an easy way to change the source template of an existing source without ending up with undefined fields. By just changing the template link no data is lost. Fields with the same shortcut stay as they are. But the other ones end up as undefined and can only be retrieved through the all tab by hand (copy/paste). I am now trying to do it in a script, but after changing the template the old data is not accessible anymore (it says: [Undefined]: the data).

Some approaches I have tried/considered:
1. Saving all the values that need be moved and after changing the template link, enter them in the new fields.
2. Creating a new source and copy all fields and delete the old source.

Option 1 is complex because it has to provide for all field types. Option 2 seems like a kind of (too) brute force.
I hope a more easy option 3 exists. Ideas/solutions are highly appreciated.

I suspect it will have to be option 1... Have you looked at the code for pCite in fhUtils to get some ideas? (It's in C:\Program Files (x86)\Family Historian\Program\Lua)

P.S. Option 2 would lead you into all sorts of trouble with source links/citations...

From my position back in v6-land, I keep an eye on things that I might want to remember. This seems one - if I understand it correctly.

I can quite imagine me trying some new source records with a particular source-template - and then deciding that some of those would benefit from a different source-template. It might, for instance, include additional items to remind me what to enter. So - I'm trying to sort out what the pitfalls could be of assigning a new source-template to an existing source-record.

Would I be right in saying that additional items in the new source-template are not a problem as such (apart from being empty in the existing source-record)?

I guess that if I remove items from the new source-template (compared to the old), then the data is only accessible via the All Tab. Not sure why I'd remove items, mind you, since I'm thinking about refinements.

And if I "rename" items in the new source-template, then again, as stated above, I lose access to the old data apart from going via the All Tab. So, for instance, if I rename "Author" to "Transcriber" in the new template, then all my old Author data is made difficult to access.

The lesson then, should I try to create an amended source-template, is not to rename anything? And try to avoid deleting anything that might still contain useful info? I think.

Does this make sense?

Adrian

One key thing is that, if you define your own custom templates, try to use the same names/types for metafields (for the same data).

Also, I think Joop is working on a 'changing the source template' plugin -- see the conversation at https://fhug.org.uk/forum/viewtopic.php ... 25#p111191

Does the Tools > Source Template Definitions... dialogue Compare/Sync with Source Template Record... button provide a solution to any of the aforementioned issues?

Mike, how would you invoke it within a plugin?

I was primarily thinking of Adrian's scenario, and maybe Joop could change the templates manually more easily than with a plugin, but certainly, that button is not available from within a Plugin. Maybe needs a new API function?

@Adrian
The first version of my plugin to change the source template of existing sources only changed the link to the template. The result is that all identical fields are available in the newly templated source and the ones that are not defined in the new template are only accessible via the all tab (as Undefined). So, as Helen suggests, the more identical fields the lesser the cleaning up afterwards.

However, I am in the process of modifying the plugin to map fields from the old template to the new as specified by the user (and allowed by field type). It will not create new fields, because I think the best way of doing this is through the Source template definition/sync tool (as Mike also mentions).

As soon as the plugin is usable I'll post it in this thread for testing.

ColeValleyGirl wrote: ↑

10 Mar 2021 11:42

... if you define your own custom templates, try to use the same names/types for metafields (for the same data). ...

That makes sense - and summarises it nicely, thanks