* [Wish List Item 626] Automatic generation of UniqueID

[Mark1834]

I left it a couple of days before rechecking, and the help link has now reappeared in the plugin description in the Plugin Store. That suggests that either there is some sort of batch process running in the background, or store admin have seen this thread and poked it manually.

I've taken the opportunity for a tidying up of the menu window to get rid of an annoying typo and to improve its general look and feel. Changes are now reflected in the Records Window prior to closing the plugin (providing it is already open with the UniqueID column visible), and the plugin now supports user font preferences automatically.

[tatewise]

Strangely, the linked Help page now does not have a link back to the Plugin download page!

[Mark1834]

Should be there now. The reverse link from the help page was blank. It was definitely filled in before (I checked specifically after creating the new help file - present and working). No idea what’s happening, but it all seems joined up again now.

[tatewise]

Yes, that all looks good now.
Is it worth trying to pursue how it got fixed? i.e. batch process, manual intervention, or what?

[Vyger]

Mark can I confirm your final revised proposal as below?

To bring this thread back to its original purpose, my revised proposal is

Proposal: A Project-level option (probably under Tools > Preferences > General > Advanced, and off by default for consistency with previous practice) be provided that when set automatically generates a UniqueID value for new Individual records added either directly from the user interface or by merging another FH project or external GEDCOM file where this field is missing.

I think this makes it clear that all I am requesting is a small addition to what FH does already. Specifically out of scope is changing the way CP have decided to implement this field in FH7.

I fully agree with this and personally would enable it immediately as UID has served me very well in my research over the years. I do notice FH use the hyphenated version of UID which I guess is compliant with Gedcom standard, regardless it fully serves the purpose.

F16F62D3-1BC5-4476-A83A-C1A08CBC7A90

I do worry a little that currently FH users are free to change this so valuable identifier to "DonaldDuck" if they wish and I have met many researchers over the years that are just intent on making changes.

[Mark1834]

Agree fully with your observations and reservation, but the primary design principle of FH is GEDCOM compliance, and DonaldDuck is a valid UniqueID.

GEDCOM 7 states that "New globally unique identifiers should be created and formatted as described in RFC 4122". The key word here is should. That has a well-established meaning - "recommended but not mandatory". Replacing should with shall, which generally means mandatory, would probably be better, but we could all find clauses in the spec to wordsmith, so I think we just have to hold our noses a bit and accept it!

[Vyger]

Agree fully with your observations and reservation, but the primary design principle of FH is GEDCOM compliance, and DonaldDuck is a valid UniqueID.

My reservation is that users can presently change this important UID whereas in other software it is hidden from the general user but then that is another matter.

[Vyger]

Wish List item 626 has been created. Please vote for it to let Calico Pie know if you wish to see this feature introduced.

[ColeValleyGirl]

Agree fully with your observations and reservation, but the primary design principle of FH is GEDCOM compliance, and DonaldDuck is a valid UniqueID.

My reservation is that users can presently change this important UID whereas in other software it is hidden from the general user but then that is another matter.

It would be a fundamental design change for FH to hide the UID. Everything in FH has always been accessible to the user.

[tatewise]

FYI: FH does 'hide' a few data tags and the Automated Record Id prevents the user from changing the value, so it should be feasible to prevent changes to the UniqueId. Maybe as a user option?

So in FH everything is not always accessible to the user.

[ColeValleyGirl]

FYI: FH does 'hide' a few data tags and the Automated Record Id prevents the user from changing the value, so it should be feasible to prevent changes to the UniqueId. Maybe as a user option?

So in FH everything is not always accessible to the user.

Out of curiosity, which tags are currently hidden, Mike?

Of course, anyone with a text editor can change the ARI... haven't got time to check if it's possible using a plugin.

[mjashby]

Sorry, but I'm still feeling a bit 'fuzzy' about how the Wishlist proposal fits with the already available Individual UID provision and option.

Application and Alteration of Indinividual UID.png (91.92 KiB) Viewed 731 times

Could someone explain how it fits with the currently existing (last) option above to:

"Generate UID (Unique ID) for Individual records where missing"

which implies that at least 'some' UniqueIDs are already being automatically created/imported/stored.

Without clarity, I'm still not convinced that users (potential voters) can reliably understand what the positive implications and benefits of the proposal would be when it seems that any 'missing' UniqueIDs can already be created.

Mervyn

[tatewise]

Mervyn, all the Wish List request is doing is allowing that manual option to be automatic if a setting is enabled.
So instead of having to remember to regularly invoke that manual option, the UniqueID get allocated automatically every time a new Individual is created.

IMO that was made very clear in the OP.

Bearing in mind that manual command already exists, most of the subsequent discussion seems unnecessary as FH must already cope with Individual records with UniqueID.

[Mark1834]

Exactly - that point was raised earlier in the thread. Much of the comment came from not understanding what FH does already.

[tatewise]

Out of curiosity, which tags are currently hidden, Mike?

Of course, anyone with a text editor can change the ARI... haven't got time to check if it's possible using a plugin.

Several of the Header record tags are hidden: _UID, _ROOT, _USED
Following many Media record links there is a _SEQ tag that is hidden in FH and I don't know its purpose.
In FH V6 the _ASID media tag is hidden.

The tags following Rich Text fields are hidden, but that is probably reasonable.

There are no Data References for the Named List data structures, so they are hidden from Queries and Plugins.

Yes, a plugin can change Automated Record Id RIN tag values.

[mjashby]

Yes, that I understand, but what I don't understand is that if 'some' Unique IDs are already being created by FH; and 'some' are (potentially) already being imported when bringing in external data:

- What (if anything) currently triggers the creation of Individual UIDs in FH, other than importing valid data and/or the manual stimulus provided by the above option? Do we know for certain that there are no built in auto-creation triggers?
- Might Calico Pie consider that the Wish is already being substantially met by existing (possibly undocumented) features?
- What are the specific/known causes of non-UID creation for 'some' Records, which obviously does necessitate the existing 'manual' creation option?

Mervyn

[tatewise]

Nothing in FH creates UniqueID except the manual command we all know about.
They may already exist in imported Individual records.
We are not aware of any auto-triggers for UniqueID. Are you?

In all other scenarios, new or imported Individual records do not have a UniqueID.

If CP already have the request under development then it won't stay in the Wish List very long.