* On Hold until 24 Oct 2024: Ability to Change Type of Fact

[LeslieP]

Would like to be able to quickly and easily change a fact from being one type to being a different type. Limitation of not changing family facts to individual facts or an attribute fact to an event fact would be expected.

For example:
Change Occupation attribute to Employment attribute
Change Christening event to Christening (adult) event

Tons of examples, tons of reasons to need or want to be able to do this quickly and easily at the individual fact level. I was frankly quite surprised to find that it isn't possible, since it's something that is trivially easy to do in RootsMagic, Legacy, and Heredis, probably also in TMG but that was long ago I don't quite recall.

It is absolutely possible to do this thanks to the Change Any Fact Tag plugin, but it's far from quick and easy.

[Mark1834]

Ideally, it sounds like what you want is to click on a fact in the Properties Box, and have an option to change that fact label along the lines of your examples. You are right to raise that as a New Wish Request, as it is not possible to provide that via a plugin.

A "change this fact" plugin could in principle have a very simple menu that presents a list of facts for the currently selected individual or family, with an option to change that value to a different fact type and copy across all the relevant information. While it would be much quicker and simpler than using the existing plugin, which isn't really designed for that task, it is still several clicks and selections rather than one. Unfortunately, plugins cannot interact with the Properties Box directly, so have no way of knowing which is the currently highlighted fact.

[tatewise]

FH v7 has been adding new Plugin API functions such as fhGetCurrentPropertyBoxRecord().
For a Plugin to work as suggested it would need such as fhGetCurrentSelectedFact() to be implemented by CP.
Then you would still need to use the Tools command to run the Plugin and select the required replacement Fact.

Whereas, a built-in FH option would be somewhat quicker, but probably much more complex to implement by CP.

So should the Wish List ask for both solutions and for the Plugin API solution hope that some kind person builds the Plugin?

[Mark1834]

On the basis that a picture is worth a thousand words, this is my "demonstration of concept" interface.

With Fred Bloggs selected in the Records Window (so it works in FH6 as well), select Tools > Change Single Fact, where the plugin has been added to the tools menu.

The top half of the box lists all events and attributes for the selected individual. The bottom half lists all available and non-hidden events and attributes. Select from the drop downs, and click OK to change. You could in principle change one event and one attribute with each selection, but the top box can also be blank to change just one.

An exactly analogous box would be generated from selecting a family.

Generating that box is precisely 9 lines of code, so it would actually be a fairly simple plugin to implement. That's the simplest method I can think of without CP making a programming change.

Capture.PNG (7.54 KiB) Viewed 7866 times

[Jane]

A couple of "got ya's" to watch out for if some one is having a go at this, would be Facts with Witnesses as the roles might not exist on the copied to fact and you might want to skip copying any sentence over-rides.

[LeslieP]

I am in awe of you coding types! To already have some sort of mockup and have investigated how to make a plugin for it, just incredible. I'm moderately capable of adapting or troubleshooting some code, but creating from scratch is just not compatible with the way my brain works.

At any rate, I do see that perhaps adding the date parameter for the item to be changed...if there are multiple occupation events, which one to change, for example.

And as for the formal wish list, I think definitely two distinct items, one for CP to add an easy menu item or drop down to change the type of fact, and the other for them to add the programming hook into the "currently chosen fact" which would seem to definitely open up the possibilities for plugins even beyond where they are now.

[tatewise]

Mark, that is a useful mock-up but is an over-simplification.
As Leslie says, it needs to cater for multiple instances of facts such as Residence, Occupation, etc.
Also, looking up Fact Types, especially with several custom Fact Sets, and Project local Fact Sets, is far from simple.
I know, as my Change Any Fact Tag plugin has to do that by reading and parsing those definition files.

[Mark1834]

It is indeed - it is a rough and ready mock-up of what the interface might look like in order to generate discussion, no more than that. I did of course look at the fact set files, and they look very logically structured.

Perhaps I'm being naively optimistic, but philosophically I feel there is always a place for the simple to use plugin with code that is relatively easy to follow and adapt. Perhaps it will only cope with 90% of user scenarios, but as long as it does no harm to the other 10%, that's fine.

I need to become more familiar with fact sets and how they work, so I'm happy to have a play over the next few days and see what develops.

[Mark1834]

Interestingly, I tested Jane's gotcha by changing a Probate fact to a Census fact in a test database. I now have a Census with an Executor! File > Validate... does not detect the inconsistency, and it appears normally in reports and on screen. It appears that FH uses fact sets primarily to determine what can be added from the keyboard, not what is allowed in the project. We'll need to get the right balance between what checking for consistency the plugin does, and what is left to the user.

[tatewise]

If you are interested take a look at Change Any Fact Tag function LoadFactsAndTags() starting at line 3250.
The relevant body code is from line 3401 to line 3444. (The rest is to do with level 1 tags that are not facts.)
I know your style and my style of coding differ, but it will give you some pointers, as handling <eclipsed> facts is tricky.
It relies on my library code for reading UTF-16 encoded files in FH v5, v6 & v7.

In the Project GEDCOM, any Fact can have Fact Witnesses with any Roles and be perfectly valid.
It is simply that the Facts tab Witness entry and narrative Sentences rely on FH defaults if no Fact Type Role definition exists.
That is the situation that often arises when GEDCOM is imported from another product and users complain that the Facts tab Witness entries and narrative Sentences are strangely presented.
Did you check the Facts tab for Executor witness person as well as the principal Census fact and the narrative sentences for both the witness person and the principal?

So in this scenario, the Plugin needs to check the original Fact Witness Roles against the new Fact Type Role definitions and warn about any that are missing.

IMO: It would make sense for File > Validate... to report Facts without Fact Types definitions, and Fact Witness Roles without definitions, and for that matter Fact Witnesses without a Role, but currently it only validates the GEDCOM file structure.
Perhaps they are something for the Show Project Statistics plugin Exception Reports.

[Mark1834]

I've had a play with this, and a first plugin is attached. It uses the same basic menu as the mock-up, but expanded to include full details of the fact to be changed, not just the name. Events and attributes are on the same menu, but it only processes one fact at a time for simplicity, so just select one and leave the other blank, as per the screen grab.

The attachment Capture.PNG is no longer available

It works with all facts in fact sets, but not (yet) with project-specific facts. I've deliberately kept it fairly simple to use and for other potential coders to understand and adapt for their own use (it's a 3 page code listing, compared with 69 pages for the full-fat Change Any Fact Tag plugin, so is obviously much less general in its application). It works on the Individual or Family record currently displayed in the Properties Box, as I found that to be more intuitive than selecting from the Records Window. It does mean that it is FH7 only though.

An important caveat is that it does not police the change for you. If you want to change a birth to a death, you can do. The changed fact will always adopt the properties of that type of fact (how it is displayed on screen and in reports and diagrams and how it deals with witnesses), so it is down to you to ensure that this does not cause problems. For witnessed facts, you have the option of keeping or discarding the witnesses. They are deliberate design decisions to keep it simple.

Any significant errors or omissions that can be corrected without adding undue complexity? As ever, try it out on a copy of your project or the Sample Project, not your live data.

[tatewise]

Some first impression comments.

1. The facts in the Original drop-lists are not presented in chronological order within the same Fact groups, making it difficult to choose the desired fact from the multiple alternatives.
2. The copied Fact does not include Citation fields and Metafields. See Copy Child Branch Fields code snippet.
3. The new Fact is added after all the others, so the user must sort the data afterwards.

[Mark1834]

Thanks Mike

1- Deliberate design decision to keep it simple. The ideal might be to maintain the full Property Box order, but that means importing Normal Time Frame details from the fact files, adding considerable extra complexity. Even alphabetical/chronological sorting priority adds quite a chunk of extra code. I'll do it if real users find it a problem, but let's get their feedback first.

2 - Good point - I didn't check the more modern Rich Text and Templated Sources options, so will add to the next version.

3 - Not sure what you mean there. When you change a fact, the Property Box updates automatically. So if sorted chronologically it stays in the same place (unless the fact is undated and you change the Normal Time Frame, such as Baptism to Probate). Alphabetical order is also maintained, so changing Census to Residence for example is likely to push it down the list. Or are you meaning something else?

[tatewise]

3 - The Facts tab is often misleading because it auto-sorts by Date.
I mean the GEDCOM/database order as shown on the All tab and as appears in Reports.

P.S.
For dated facts, it would usually be easy for the user to use the various sort options to restore the original order.
For undated facts or multiple facts with same Date, the user may have crafted a special order, which will need to be recrafted.

[Mark1834]

OK, clear. It feels like an issue that is well down in the 10% I described earlier, but let's wait and see...

[tatewise]

I have not investigated in any depth but the New Event and Attribute droplists do not list all the available facts.
There are many omissions among which for me is the standard Christening (adult) event.
I have many Fact Sets including some downloads from the KB such as Birth or Baptism2, Death_or_Burial1, Electoral_Roll, Military, Name Changes, Travel1, etc.
There seems to be no particular pattern with arbitrary facts included/omitted from several Fact Sets.

A quick review of the plugin code reveals that it is ignoring the GroupIndex.fhdata file that determines Fact Set precedence.
That may affect which Fact definition is active and not <eclipsed> especially when it is Fact Name that determines which facts are <eclipsed> and not Fact Label, which may differ for facts with the same Fact Name.

[Mark1834]

I can see a typo in one of my matching patterns for parsing the data file, so I suspect it is that. My first prototype used slightly more long-winded code for parsing definitions, and worked fine. I changed it to a pattern for conciseness but clearly didn't correctly anticipate all possible values. I put in an error trap to check that all available definitions had been extracted, but not a second one to check they had been parsed correctly. I'll fix it tomorrow, finished at the desk for today.

[ColeValleyGirl]

If it helps the multifact plugin includes code to read all the fact set files taking precedence into account

[LeslieP]

Results of quick test:

• ORIGINAL section in property box order, TARGET section in alphabetical order makes perfect sense and is intuitive.
• Plugin only runs if property box is open, facts tab doesn't have to be selected. This makes sense, but maybe eventually add an error msg if someone tries to run it when property box is closed.
• Adding witness role types for the target would be great, but until that's done, the notice could be clearer that if the role type doesn't exist, the role will be blank so the user needs to make a note of it before doing the change. Since there is actual "data loss" of the role types, a scarier kind of warning might be a good idea.

Really excellent plugin! Still think this should be incorporated by CP into the program standard, but until that time, this plugin is a winner!

off topic question
Discovered that Residence is an attribute rather than an event, but it doesn't have an active value field, so that's weird. It's a standard fact, is my system wrong?

[tatewise]

As I said earlier the Change Any Fact Tag function LoadFactsAndTags() starting at line 3250 and relevant body code from line 3401 to line 3444 performs all the precedence handling of multiple Fact Sets.

Leslie, in my tests the ORIGINAL section is NOT in property box order but in alphabetical order.
Maybe your chosen Property Box just happens to have its facts in alphabetical order?

It is not clear what happens to Roles when Witnesses are copied and the message does not explain anything about Roles.
Why not copy the Roles, Sources, Notes, etc, unconditionally if the Witnesses are copied?

Actually, the more I experiment, it appears that various Fact sub-fields are not preserved.
Any attached local Media or linked Media record is not fully preserved with all sub-fields.

Yes Leslie, the standard Residence attribute is an anomaly as it has no value. That is normal and is in the GEDCOM spec.

[LeslieP]

Leslie, in my tests the ORIGINAL section is NOT in property box order but in alphabetical order.
Maybe your chosen Property Box just happens to have its facts in alphabetical order?

Yep, alphabetical it is! I needed to be looking at someone with more facts. Derp

[Mark1834]

OK, good steps forward now thanks to your input -

1. Missing subfields and meta data were caused by not correctly copying old fact to new. It copied subfields, but not recursively so only the top level and did not copy meta data. Now fixed.

2. Missing new facts were caused by a malformed pattern match that omitted labels containing some non-alphanumeric characters. Now fixed.

3. Parsing fact definitions was affected by not correctly determining the size of tables. I've fixed it, but I'm not sure I fully understand how the problem arose. I'll start a new thread on that topic later if I can't figure it out, as it is a more general issue than just this plugin.

4. I have removed any special handling of witnesses, as it is not necessary and can cause confusion. Witness details are fully copied along with all other fact data.

5. The plugin warns if the Property Box is closed or does not contain an Individual or Family Record. Previously it just exited silently.

I need to better understand fact set precedence and fact eclipsing, so I'll look at that before posting the update to avoid having too many alternative versions. It may be a day or two before I have time to do that, but I'll post the update when I can.

[arthurk]

As I'm still on v.6 I can't try out this plugin, but I did occasionally use the built-in function when I was using RootsMagic. I seem to remember that you invoked it not by selecting an individual and then picking from a list of facts, but by first highlighting the fact in the equivalent of the property box, and only then selecting the option to change it.

I've no idea whether that could work in this plugin, but it would at least remove the need to work out how to present a list of existing facts to choose from.

[Mark1834]

That’s the ideal solution, but plugins have no way of knowing which fact is selected. Hence the wish list discussion earlier in the thread.

[tatewise]

Arthur, as explained earlier in this thread, it is not possible for a Plugin to determine which Fact is currently selected.
It is only in FH v7 that a Plugin can determine which Property Box is open, so the Plugin would have to go through the Record Selection dialogue to work in FH v5 or v6.

This is one of those catch 22 scenarios. Ideally, CP would implement a built-in feature similar to RM.
Now that a Plugin exists to satisfy 90% of the need, the pressure on CP is removed, so a built-in feature may never happen.