Using settings when using the content of the clippings cart

[hartenthaler]

Up to now we discussed using settings as a combination of start/stop persons and options. What happens if the clippings cart is used as the source for individuals and families?

First: I would expect when there are individuals in the clippings cart and a settings is loaded that defines at least one start person that in this case the clippings cart is not used.

Second: when I'm storing a setting when using the clippings cart I can see two options:

1. The setting contains the actual options including the option "use the clippings cart". When loading such a setting later the then actual clippings cart is used.

2. The setting contains the actual options and a (maybe long) list of all XREFs of individuals, families and media objects from the clippings cart. When loading such a setting later there are again two options
   2.1 the clippings cart is replaced by the XREFs from the settings if they still exist (I still have to deliver this function to write to the clippings cart (open issue)).
   2.2 the clippings cart is not touched, but the original list of XREFs from the settings is used.

My preference is 2.1, what is your opinion? 2.1 adds as a sideffect a new function to webtrees by (mis-)using GVExport: storing content of a clippings cart in a user/tree setting (without XREFs of SOUR, REPO,_LOC, NOTE, SUBM).

In general: using XREFs in settings which may exist for a long time is not a good idea, because during the time the XREFs may be changed for example when merging trees. It is OK when there are stored only a few XREFs as start/stop persons. It becomes more dangerous if there are stored many XREFs in a setting.

[Neriderc]

Option 2 seems to make sense more than option 1. Option 1 seems confusing for users, however, there are some potentially confusing things in each option.

You are right in that storing XREFs long term is a risk because they can change, but I don't see what other option we have. It's the only unique identifier we have for a record. We are lucky they only change occasionally (such as with merging), trying to use names or other personal details would be much worse, as the details of some record or another are frequently changing.

Ideally we would have a way to update the XREFs when they are changed in webtrees, but I expect this is easier said than done. I think we should just accept this risk. We could filter out invalid XREFs, but the current system leaves them there showing as an XREF rather than a name. This lets you know that there is someone missing, rather than silently removing them and not telling the user.

For 2.1, it does seem to be the preferable option. I do have a few concerns/thoughts. Firstly, what happens when the user already has something in the clippings cart? Do we add to it? Overwrite it? Perhaps warn them, then overwrite?

Secondly, there are a lot of record types that are not individuals. Do we simply list these as XREFs in the xref list, with a setting also indicating that they are XREFs intended for the clippings cart?

[hartenthaler]

Ok, so we agree on 2.1 and we agree on the risk of storing XREFs. In principle, we could generate other unique IDs using for example UID (or _UID), but let us use XREFs because other options will produce a lot of new problems and are not supported very well by webtrees. I don't see a chance to get informed if an XREF changes. We should not filter on not any longer existing XREFs (let happen whats happen in such a case). We could spend one or two sentences about that in the manual of GVExport.

If there is already content in the clippings cart when a user loads a setting with additional XREFs then add them to the clippings cart, because that is what the clippings cart is for (collecting XREFs from different sources). The user should be familiar with that behaviour (no warning). If he/she likes to see only the XREFs from the settings to be visualized he/she is responsible to clear the clippings cart before adding a new set. Each XREF can be stored only once in the clippings cart.

IN GVExport we are using three types of XREFs:

• INDI
• FAM
• OBJE
  They are never listed in the GUI but are visualized in the diagram. They have to go to the XREF list in the setting. I suggest to store all INDI XREFs and only the XREFs that are related (XREFs of FAM and OBJE needed by GVExport).

There are maybe other types of XREFs in the clippings cart, as well. The XREFs for SOUR, REPO, NOTE, SUBM, and _LOC are not used by GVExport. I suggest ignoring them.

[hartenthaler]

Saving a settings when using the clippings cart should be:

• save all XREFs from the internal GVExport lists (INDI and related FAM and OBJE XREFs) to the content of the settings
• save all options including "use clippings cart")

Loading a settings that uses the clippings cart should be:

• activate the clippings cart modus (ignoring start/stop individuals)
• copy all XREFs from the setting to the clippings cart
• read the clippings cart using the already existing function to build up the internal GVExport lists.

[Neriderc]

Thanks, I think I understand how this is intended to work.

As you've mentioned, this relies on #177, so we can park this until that is done and then I'll take a look. No hurry, just get to it when you have time.

[hartenthaler]

Tomorrow our vacation on Bali ends. So after some time to reorganise our life in Berlin, I like to do it.