* Add GRO Source plugin

[Normie]

Helen

I agree all the information is there, but it takes an effort to find it on the various FH pages. My suggestion was just to post that information on the plugin store.

You are right, my plugin is a standard plugin, but it does create a prepared citation when it runs; i.e. it becomes the current prepared citation and then follows the similar process as your DEA version. In fact the code would have much simpler, if the citation phase was not adopted.

As an aside, I have modified the Gravestone template, so that each person on the gravestone has their own citation, linked back to the source for the gravestone itself.

I will look at the thread you have suggested.

As you say, all programmers will take a different approach.

Norman

[ColeValleyGirl]

Helen

I agree all the information is there, but it takes an effort to find it on the various FH pages.

Agreed.

My suggestion was just to post that information on the plugin store.

For 7 plugins, that would be a fair bit of work...

[gsward]

Step 1: Prepare a citation to the appropriate Civil Registration Index source:

These notes would be really useful if they were at least on the relevant Knowledge Base page i.e. a V7 version of https://fhug.org.uk/kb/kb-article/recor ... n-sources/

As to the inefficiencies, whilst I appreciate the name of the person at registration might differ from the person you are recording it for, in the great majority of cases it's not, so I would prefer not to have to enter the name but accept that in a few cases I need to adjust manually. The other frustration was not having a lookup or be presented with a list of Registration Districts. In that respect, Norman's version is far more elegant. In my case Norman's plugin works rather well as I have all my previously entered registration districts beginning "GRO District" so they all come neatly to the start of the list. There is a small enhancement that would make Norman's version even better, but I will reply separately on that.

Thanks,

Graham

[gsward]

Birth and marriage versions attached.

CRD(UK) Marriages.fh_lua
CRD(UK) Birth.fh_lua

Let me know if you have any issues or questions.

Norman, as I have said these do work well. As I am coming to this as a long-term user of the Add GRO Source plugin. That of course uses three pre-prepared sources, However, when it creates the actual facts it inserts "Registration District" in the Address fields alongside the Place. To maintain backward compatibility would it be possible to add that feature? (You even may be able to copy the code snippet!)

Thanks,

Graham

[Mark1834]

I'm not sure I've got the time to do the detailed documentation for all the existing DEAs. I'd rather concentrate on the new one that I'm writing!

Isn’t the danger that we just end up with more under-used DEAs, if users find the process too complex?

On the other hand, my priority would be to keep the workflow as simple as possible so you don’t need extensive documentation. I tend to take the view that if I understand what the software does, the detailed manual is there for reference, not something you need to get past first base. The process should be intuitive from the user interface. If it’s not, it is too complex.

That’s why I think these simpler dedicated plugins that are emerging are an interesting development.

[ColeValleyGirl]

As to the inefficiencies, whilst I appreciate the name of the person at registration might differ from the person you are recording it for, in the great majority of cases it's not, so I would prefer not to have to enter the name but accept that in a few cases I need to adjust manually.

Graham, if you're creating a new individual, their name is set from the name in the Prepared Citation, because that is presumably the only name you know for them. So no need to adjust it.

If you're adding a birth to an existing individual, their existing name is retained; the name in the Prepared Citation is only used to create the Text from Source. And if you have the correct individual selected before you run the DEA, their record is selected for you as well, so no need to modify that either.

The other frustration was not having a lookup or be presented with a list of Registration Districts. In that respect, Norman's version is far more elegant. In my case Norman's plugin works rather well as I have all my previously entered registration districts beginning "GRO District" so they all come neatly to the start of the list.

Nothing I can do about that -- when you're entering the Registration District, you're talking to FH not the DEA. You could clone the Source Template and change the relevant field to be an Enum (dropdown) with the list of Registration Districts as possible values... Maybe not all of them initially but the ones you anticipate using (you can add to them when preparing the Citation if you encounter a new one). You'd need to give the template a different name, and to make a one line change in the DEA.

However, that would be a lot of work to go to when you've already got an alternative you like.

[ColeValleyGirl]

On the other hand, my priority would be to keep the workflow as simple as possible so you don’t need extensive documentation. I tend to take the view that if I understand what the software does, the detailed manual is there for reference, not something you need to get past first base. The process should be intuitive from the user interface. If it’s not, it is too complex.

I agree about complexity, which is one reason I'm not keen to spend time documenting the existing DEAs further. But my view of a simple workflow might not be the same as yours.

[Normie]

Norman, as I have said these do work well. As I am coming to this as a long-term user of the Add GRO Source plugin. That of course uses three pre-prepared sources, However, when it creates the actual facts it inserts "Registration District" in the Address fields alongside the Place. To maintain backward compatibility would it be possible to add that feature? (You even may be able to copy the code snippet!)

Looking at the the Add GRO Source Plugin, all I think you are asking is can the address field be populated with the text 'Registration District'.

Is so that could be implemented in a number of ways. To maintain flexibility, I suggest I add a new Address field under Registration District. When you save an entry, I can save that value and prepopulate it the next time (as I do for Assessment). What that would mean for you is that you have to type in 'Registration District' for the first entry only.

If you have a real Address, you could type it in there, and that would be recorded. If the field is blank, then it is the same as it is know.

Does this meet your needs, or do you have a better option.

Norman

[gsward]

Norman,

That would be perfect.

Thanks,

Graham

[Normie]

Graham

I made the changes I suggested. I have only done limited testing, but hopefully does what you want.

CRD(UK) Death.fh_lua

(22.5 KiB) Downloaded 35 times

If this works, let me know and I'll make the same changes for Birth and Marriage.

Regards

Norman

[gsward]

Norman, yes it works exactly as I expected and retains the Address information for the next time.

Thanks,

Graham

[Normie]

Good.
I'll make the changes to Birth and Marriage versions and post them tomorrow.

Norman

[Normie]

Graham
I've attached the corresponding plugins for birth and marriage.

CRD(UK) Marriages.fh_lua

(23.43 KiB) Downloaded 34 times

CRD(UK) Birth.fh_lua

(21.08 KiB) Downloaded 43 times

Norman

[gsward]

Thank you!

[tatewise]

The problem in this case is a little complex.
Add a General Record Office Source and optionally Event V1.3 is in the Plugin Store for FH V6 and Author Jane Taubman.
An updated version called Add GRO Source was attached by Jane Taubman very early in this thread.
In response to user demands, I have attached later versions to this thread for FH V7, etc.
Since Jane Taubman is the Author of the Plugin Store version, only she can update it with the later versions and that is why the latest plugin versions only exist as attachments.

[ColeValleyGirl]

Mike , there are other plugins attached in this thread.

Have you asked Jane to ipdate the store?

[Pentris]

The GRO Source plugin in the store is only up to FH V6 and is 4 years since updated so is no good for V7.

[tatewise]

Mike , there are other plugins attached in this thread.

Have you asked Jane to update the store?

The 'other plugins' have only been attached this month and I'm not sure how different they are.

I'm sure I've asked Jane in the past, and she took part in the early discussions so was aware of the situation and it has been a regularly recurring thread.
I can ask her again...

Before anyone asks, no I don't want to take on this Plugin as one of my own. I have too many already!

[jelv]

The GRO Source plugin in the store is only up to FH V6 and is 4 years since updated so is no good for V7.

I'm using Add GRO Source version 1.3.4 (attached to this reply: viewtopic.php?f=42&t=16641&start=50#p106661) on FH V7.

I've tried using the Civil Registration Index source template and associated DEA and find it a lot slower than Add GRO Source. The worst feature is that when you start from Prepare Citation to Existing Source you have to find and select the appropriate source every time.

When recording deaths, if it is a more recent one that gives the date of birth, I enter that in the Recorded Age at Death field in the format b. dd/mm/yyyy which then goes in the citation. It does mean that if I don't already have a DOB I have to amend it manually and add a copy of the citation.

[Normie]

I'm starting to try out your three CRD(UK) xxxx plugins and they do look very promising and a lot easier to use than the DEA method. I do have at least one suggestion on the Death one, so if you'd like to start a new topic with the latest versions attached I'll comment on there rather than further contaminate this topic which is supposed to be about the Add GRO Source plugin.

As requested I have started a new topic viewtopic.php?f=42&t=21444

[tatewise]

I have been persuaded to formally publish the 'Add GRO Source' plugin in the Plugin Store for FH V7, and after approval, it will exist as Add GRO Index Source Citation Version 1.0 Date 26 May 2023.

Then all attachments of the 'Add GRO Source' plugin will be deleted.

[Normie]

I have been persuaded to formally publish the 'Add GRO Source' plugin in the Plugin Store for FH V7, and after approval, it will exist as Add GRO Index Source Citation Version 1.0 Date 26 May 2023.

Then all attachments of the 'Add GRO Source' plugin will be deleted.

Just to avoid confusion, I posted my version of this in the plugin Store on the 19 January under the title 'Add GRO Index Entries'.

As you appear to have written an alternative, it makes sense that my version is withdrawn from the store after your version is added. I assume you can make this happen.

[ColeValleyGirl]

Just to avoid confusion, I posted my version of this in the plugin Store on the 19 January under the title 'Add GRO Index Entries'.

As you appear to have written an alternative, it makes sense that my version is withdrawn from the store after your version is added. I assume you can make this happen.

The Plugin Store actively encourages overlapping plugins:

If you have written a new plugin, or even if you have adapted and significantly improved somebody else’s plugin, please consider submitting it to the Family Historian Plugin store. You can do so pseudonymously if you wish, or you can use your real name – it’s up to you. Obviously if yours is the the first plugin for a particular purpose, it will be greatly valued. But even if there are already plugins that do a similar job, please consider submitting yours anyway. Different plugins may have different styles or benefits. It’s good for users to have a choice. Any user can download and install plugins for the same or similar purpose if they want to, and easily compare them; so there’s no problem about having overlapping plugins. It’s also not a problem if you have created your plugins by adapting someone else’s plugin – even if you previously downloaded that plugin from the plugin store.

Also, I'm pretty sure Mike doesn't have admin access to the plugin store, as it's run by Calico Pie and not FHUG.

[tatewise]

The two plugins have significant differences so they can coexist.
The biggest difference is yours uses Templated Sources and mine uses Generic Sources like Jane's plugin it supersedes.

I would be happy if you would like to amalgamate them into one plugin that caters for all the options they both offer.

As Helen says, I don't have admin access to the Plugin Store. There is supposed to be a Plugin 'Move to Bin' option to delete it but the last time I tried, it did not work and I need to report that to CP.

[Normie]

Mike

Thanks for clarifying this.

As you say, mine is based on templated sources and thus I suspect will be quite different to yours. Given that, I accept it is appropriate to have both versions available; assuming that the difference is obvious to users.

I will leave my version in the plugin store.

Norman