Family Historian User Group

Before I embark on writing one, does anyone have a Lua code snippet to convert Facts of a specified type into Note records, and to convert selected Note records into Facts of a specified type?

I don't have a snippet for that, but the plugins:code_snippets:copy_child_branch_fields|> Copy Child Branch Fields (code snippet) might be a good starting point, because that parses the nested fields within a nominated Fact.
The CopyBranch(...) statement fhSetValue_Copy(...) would need to become a Note text composing function.
Probably the best solution would be a table.insert(...) and when the parsing completes then use table.concat(...) and fhSetValueAsText(...) to save to the Note record.

Have you considered how to identify each Fact field as a labelled text line in the Note record?
It will have to cope with fields nested within fields to an arbitrary depth.
e.g.
1 Occupation: Labourer
2 Date: 5 Jan 1953
2 Place: Lewisham, London, England
2 Source: @S123@
3 Media: @O321@
3 Where: Page 25
3 Data:
4 Date: 1953
4 Text: Transcript
3 Note: @N21@

That will allow the reverse process to parse those labelled text lines using a complementary version of the code snippet.

Has your code got to cope with EVERY possible Fact syntax, nested fields, linked records, etc?
If so, how will it cope with links to Fact Witness, Note, Source, Media and (rarely) Family records?
Have you considered Family Facts (such as Marriage & Divorce) and how to identify Custom Facts/Attributes.

Thanks, Mike. These will be very specific facts (Research Tasks for Individuals created by version 1 of the Research Planner plugin -- attributes with no Place or Address fields but optionally an attribute value and a fact date).

Going from Facts to Notes, any Source details will become Source details for the Note record; and the Fact note will become the content of the Note record (prepended with the Attribute and the Fact Date if there is one.) The Note record will be linked to the individual who owned the Fact. The Fact will be left in place for the user to delete when they're happy with the conversion.

Going from Notes to Facts, the Note text will become the Fact Note with a piece of labelled text taken out to become the attribute value (if the text exists). Source details will become the Source details for the Fact. Fact Date will be left blank. The Fact will be linked to the user to whom the Note was linked. The Note will be left in place for the user to delete.

OK, that does simplify things a great deal.

Presumably the labelled text lines for Attribute and Date will be distinct enough to avoid them ever occurring in Note text, or will that also have a label?

Have you considered what happens if a user edits the Research Task Fact or the derived Note record?
That may introduce extra Fact fields or corrupt the Note layout; may be serves them right?

Do the Facts and Notes to be reviewed and deleted need to be 'marked' in some way so the user can easily locate them? e.g. Facts could gain a unique field, and Note records gain a Custom Id.

Attribute will be labelled with a label configured by the user; and Fact Date will be labelled "Due Date:" (or I might just ditch the Fact Date -- it doesn't serve any real purpose in a Note; it's just optionally available for a user to sort Facts more finely that the Fact timeframe allows.)

If the user edits the Fact definition to include extra fields, they won't be transferred.

Converted Tasks will acquire a #ConvertedTag and the next version of the Research Planner will come with queries (one for Facts, one for Notes) that can filter on tags in the Note text (as well as a number of other fields). I may also include a Utility in the Plugin to display a result set that includes Notes and Facts. (It's a pity that Plugins can only have a single Result Set...)

This conversion is intended to be a tool to help people change how Research Tasks are recorded -- the plugin will offer options for Facts or Notes, and people who have started off using one method may want to change to the other. I don't expect it to be used very often.

OK, understood.
It is probably of no consequence, but if a user runs a Plugin like Order Facts by Sort Date then every Research Task Fact will gain LMO Sort Date subfields, etc.

That's exactly why the user who has asked for Fact Dates wants them

But even a Research Task Fact without a Date will gain a default LMO Sort Date structure.