I have an gramps 5.2.4 database which defines custom event role types, including the role type ‘Father’. These custom role types are used by the Forms gramplet to identify participants in a Form.
In gramps 6.0, after importing a 5.2 database, I see two ‘Father’ role types.
When the 5.2 Form data is displayed in 6.0, the “Father” role type values do not match and the data is not shown in the form. This gives the impression to the user that all form data for this participant has been lost. In reality, all the data is still there, it’s just the role type that is now “wrong”. Editing the event ref and setting the role back to the first ‘Father’ value “fixes” the problem.
@Nick-Hall assuming the above analysis is correct (and I’m not 100% certain yet), there could be user databases that need “correcting”.
Exporting the database to a .gramps file and importing into a new database also appears to fix the problem. I assume it correctly maps the string ‘Father’ to the value 11.
Steps to Reproduce
using gramps 5.2.4, install the Forms gramplet
add a new source, name “UKBirth” and add an attribute called “Form” with a value of “UKBirth”
Create a new person with givenname of “Father”
Using the Forms gramplet, add a new UKBirth form
select the “father” person as the father and click OK
display the form again to confirm that the father is correctly shown
exit gramps 5.2.4
using gramps 6.0.6, install the Forms gramplet
open the database created in steps 2 to 6
display the form and note that the Father is not shown
Yes. This will cause a problem for people who upgrade their database.
Both the Gramps XML and the form definitions store the role as a string. The string “Father” will be read in as a custom type in v5.2 and a pre-defined type in v6.0. I see 4 places in the editform.py file where the role in the database is compared to a role from the definition file. (lines 850, 1033, 1222 and 1295).
We can fix this by either changing these 4 lines to do a string comparison or upgrading the new roles in the database.
Anyone who imports a Gramps XML backup into an empty database when upgrading will be unaffected. This is why I haven’t encountered the problem.
Option 1: Create a database backup. Then create a new database and import the backup. This should take the custom “Father” role and set it as a coded role. If everything resolves itself, you can delete the old database and rename the new to your preferred name for your tree.
Option 2: Use the Type Cleanup tool. This will identify your custom entries. Rename the custom role to “Father X”. Then rename it again by selecting “Father” from the available list of options. Renaming the custom entries first allows you to differentiate the custom and coded types in the drop-down list.
Thanks for confirming Nick. I think it is better (although maybe not easier) to upgrade the roles in the database. Ideally we’d have done this during the schema 21 updates for v6.0. Alas, that ship has sailed Whilst we can update the Forms gramplet more easily, we do not know what other code may be impacted in a similar way.
I’ve only just updated my personal tree to v6.0. I was fortunate enough to be able to debug the problem but I can imagine a typical user being very concerned at the apparent loss of some of their Forms data. @DaveSch presents a couple of workarounds, but in my view we should handle this automatically in the core.
Is changing db schema in a point release a good idea or is there a better\another way to achieve this?
Whilst we can update the Forms gramplet more easily, we do not know what other code may be impacted in a similar way.