Question Customization of GEDCOM tag visibility

While webtrees offers some configuration options for GEDCOM tags in the control panel, there is no fine-grained configuration for each single tag. This has been discussed on the forum and e.g. here .

I'm experimenting with additional configuration options in the latest release of the custom module '⚶ Vesta Classic Look & Feel'. The idea is to allow admins to configure which tags to show, per event – not via the control panel (the amount of required options may be overwhelming), but on the respective event itself.

As an example of the work flow, if you miss a field on 'Death' events, edit such an event and select 'Edit with all GEDCOM tags'. That edit dialog is enhanced with a new checkbox 'Configure visibility of GEDCOM tags' at the bottom (which is only visible for admins).



Checking this box reveals icons on each single tag, which in turn allow to configure the visibility of the respective tag for the specific event for all future edit dialogs (i.e. the initial dialogs, not the 'Edit with all GEDCOM tags' version, which is never affected).



I'm not quite sure this is the best way to manage the large number of configuration options - It seems useful for single events, but less so when you want to show/hide the same tag for different events. Let me know if you have any feedback on this!

(Note: this should be considered a 'beta' feature in Vesta. If I keep it, there will be further cosmetic improvements. This initial version is intended to determine whether the overall work flow is useful)

I'm trying to wrap my mind around where this configuration would be implemented and how it would be stored. I have not moved to v2.1 so correct me if I'm wrong, but the configuration right now is based on hard coded PHP, either 1) default tag display -or- 2) all tag display.

You said:

The idea is to allow admins to configure which tags to show, per event – not via the control panel (the amount of required options may be overwhelming), but on the respective event itself.

This sound like it would happen at data entry time (you indicated "edit" which actual would be after you entered the data and saved), which means that the event/fact would first get entered without some information, then "edit" the event/fact marking the additional tags to be included and editing the information. And this would only have any bearing on the current event/fact not any future entries of the same fact.

I'm not sure of the value beyond the "Edit all GEDCOM tags" selection if I wanted to add CAUS where it was not included in the default tag display! Once data is entered in a tag, I thought it would always be displayed even when it was not part of the "Default display" tags set!

I'm not a PHP coder and the only equivalent way that I have implemented configurable field display (i.e. display on the same screen fields based on a profile) is by creating a data dictionary tied to the profile, where the screen is built based on the profile (for this exercise Fact/Event rather than User) and building the screen out of selected fields for that profile. This is similar to what I think is happening PHP elements folder for various tags except it is changed to database driven vs code driven as it is now.

But again I may be way off target on how this gets implemented!

norwegian_sardines wrote:

I'm not sure of the value beyond the "Edit all GEDCOM tags" selection if I wanted to add CAUS where it was not included in the default tag display!

That is exactly the use case. It is helpful to always have CAUS available directly if you regularly want to use it, instead of having to open "Edit all GEDCOM tags" and having to navigate through lots of exotic tags which you aren't interested in. Conversely you can reduce the number of tags shown initially, which may be useful in particular when creating a new individual.

The additional configuration is stored as a tree preference.

norwegian_sardines wrote:

And this would only have any bearing on the current event/fact not any future entries of the same fact.

No, it affects all future edit dialogs. The edit dialog itself is just used additionally for the configuration, this could be moved to the control panel instead. Having it here simplifies the workflow (at least that is the idea).

Ich finde es gut die Eingabemasken nicht an den den Gedcom Definitionen auszurichten. Der Eingebende sollte, so wie Richard es vorschlägt, die Möglichkeit haben, die Felder entsprechend seinen Wünschen auszuwählen und möglicherweise auch noch deren Reihenfolge.

I think it's good not to align the input masks with the Gedcom definitions. The inputter should, as Richard suggests, be able to select the fields according to his wishes and possibly also their order.

Das ist auch ein Grund mit, warum ich webtrees bisher nicht zur Eingabe verwende.

Rick said:

The additional configuration is stored as a tree preference

So you intend to have an additional database field or fields that store the preference -or- are you talking about module extensions to the current PHP element definitions?

Franz said:

I think it's good not to align the input masks with the Gedcom definitions. The inputter should, as Richard suggests, be able to select the fields according to his wishes and possibly also their order.

I never said I was against more granular tag display, my concern was,
1) were the preferences of sub tags by fact/event or global
2) where were the preferences stored,
3) the use of “edit” which to me says “after the initial data was entered”.
Order of entry would be an added convenience. HOWEVER, he is not suggesting all data entry people would have the option of adding the ability to include the CAUS tag (this is still a function of the admin), just that they can add the data associated with this tag if the admin allows it!

Since the display of subtags such as CAUS appears to be controlled by fact/event php code, would it not be better to change the PHP code as part of the configuration? My understanding is we are only talking about level 2 subtags of fact/events which has only a few options {TYPE, DATE, PLAC, ADDR, AGNC, RELI CAUS, RESN, NOTE, OBJE, SOUR}, of which only TYPE, AGNC, RELI, CAUS and maybe ADDR should be regularly non-display! If we go down to level 3 tags then we will have more, PLAC:MAP is one example that I would never want displayed!

So, I would rather see granularity configuration as part of the admin function, keeping some code complexity out of the data-entry side and place it were it belongs in the configuration area.

If the fix is really based around extending the element based PHP code, then maybe some fool proof code examples of changing the default elements would be better, rather than writing more configuration front-end code.

An important thing to keep in mind is, what about subtag definitions that are not part of standard GEDCOM but have been introduced by other GEDCOM dialects? They will want their tags too so they can “round-trip”!

norwegian_sardines wrote:

So you intend to have an additional database field or fields that store the preference

Yes, in the table 'wt_gedcom_setting', just like other tree-specific settings.

norwegian_sardines wrote:

would it not be better to change the PHP code as part of the configuration?

I'm not sure I understand this. If you make changes to the php code, you'll have to repeat this after each new release. How is that useful?

norwegian_sardines wrote:

So, I would rather see granularity configuration as part of the admin function

It is an admin function. You'll usually ignore it on data entry, the additional checkbox at the bottom of the edit dialog is intended to be very unobtrusive.

norwegian_sardines wrote:

An important thing to keep in mind is, what about subtag definitions that are not part of standard GEDCOM but have been introduced by other GEDCOM dialects? They will want their tags too so they can “round-trip”!

These tags are just as configurable as regular tags - anything that appears in the edit dialog is configurable.

Richard,

As usual I can’t explain my ideas so they have no value, so I’m out! Have fun with you modifications.

It is not a modification I would ever use anyway if I was to move over to v2.1

@Richard: this is a very helpful configuration option!

I adjusted now most of the data input menus and it works like a charm! Easy to use and results in a better user interface.

It was a good idea to configure the menus if you have them just opened instead of configuring them in the control panel in an abstract and overwhelming list.

Funktioniert soweit und hilft zur Anpassung der Eingaben.

bug: Ausschalten der Eingabemöglichkeit für "Ereignis ist eingetreten, aber ich habe keine näheren Infos" geht nicht (Geburt und Ehe getestet).

Aus den 2 Zeilen für "Verbundene Personen" (FAM:MARR:_ASSO) kann man nicht eine Zeile machen.

Wenn man jetzt noch das Klicken auf die Bleistifte ausbauen könnte ( also alles in einem Formular ), dann überlege ich mir, ob ich die Eingaben über webtrees mache. So sind mir das immer noch zu viele Klicks.

Thank you all for your feedback!

@Ken I appreciate your feedback, I apologize if my replies came across differently, they weren't intended to discourage further conversation.

I think it would be relatively easy to evaluate a custom order of tags, but the configuration dialog would have to be more advanced (allow to drag and drop tags to obtain a custom order?), I'm not sure how this could be integrated with the existing edit dialogs.

@Franz note that you can enter data for different events within a single dialog when creating new individuals. For existing individuals, potentially with a large number of events, a single dialog isn't that useful in my opinion. By the way, webtrees actually supports this internally via its generic 'edit-record' method ( see this example from the demo server when logged in as editor, or test with a similar URL locally).

Danke für die Hinweise.
Ich muss gestehen, dass ich in WT bisher noch nie eine neue Person erstellt habe.
Mit deinen Erweiterungen wird die Benutzerfreundlichkeit mächtig gesteigert.

It sounds very good, but I do not have now time to test this version.

My question is it possible to make the location (shared place) visible when adding individuals/events? In the latest versions I have tested it was always necessary to click on the small triangel to have possibility to enter location( (shared place).

Yes, it is possible now.

@Ladislav You mean as an additional option to initially expand specific subtags automatically? That should be relatively easy to implement. I'll add it in the next release if that's actually the case.

Maybe I'm wrong, but if you configure the visibility of the shared location to "show always", then the submenu of a location is now always expanded and you can edit the shared location directly. Before the configuration of GEDCOM tag visibility was available the submenu was always closed and you had to expand it before you can edit the shared location.

hermann wrote:

if you configure the visibility of the shared location to "show always", then the submenu of a location is now always expanded

I cannot reproduce this (note that the submenu is always expanded as soon as there is any value set). In any case, it would be an unintended effect.

ric2015 wrote:

@Ladislav You mean as an additional option to initially expand specific subtags automatically? That should be relatively easy to implement. I'll add it in the next release if that's actually the case.

Yes exactly - this is the main reason for me not to upgrade to 2.1. Of course - this expand should be executed for all facts and events.

rola wrote:

Of course - this expand should be executed for all facts and events.

Configuring the visibility for all facts and events is currently not supported. Adding this and the 'expand' option would result in a dialog like this (this is just a mock-up, not implemented yet):



Would this actually be useful or too confusing?

ric2015 wrote:

Configuring the visibility for all facts and events is currently not supported. Adding this and the 'expand' option would result in a dialog like this (this is just a mock-up, not implemented yet):

Would this actually be useful or too confusing?

It would be useful.

On the other hand I see now, I started something in a wrong thread. From my point of view PLAC (and _LOC) are so prominent tag(s) so they shoud be handled "separatly". So I think there should be a general information in settings "We use Locations (Shared places)" and when this is set the entry field for it will be automaticaly visible. Perhaps we even dont need a new config option - using Vesta Shared place modul or "GEDCOM-L show" in Control panel/CEEDCOM tags could indicate this.

For future reference: The functionality is extended as described above in the latest Vesta release and may now be considered 'stable'. I do not plan to support re-ordering of tags here.