merge data from two different family-trees faulty

Bug #770024 reported by Dirk Herberich
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
webtrees
Fix Released
Wishlist
fisharebest

Bug Description

Hi Greg, all,

I have just uploaded a new family tree to webtrees 1.1.2. I have now tried to merge some records. These records are in two different family trees. The cross-reference between the individuals and families in the two family trees does not seem to work well yet. For instance: The family record from the file that I merged in is now reported as an error as follows: "Unable to find record with ID F846351081"...

Greg has a login to the Herberich-Database. You can have a look at this record to observe the fault: http://herberichfamily.com/webtrees/individual.php?pid=I544
If anybody else needs a login, screenshots etc. please let me know.
dirk<d-o-t>herberich<a-t>gmail<d-o-t>com

Hope the info provided is sufficient.
Thanks,

  Dirk

Revision history for this message
kiwi (kiwi3685-deactivatedaccount) wrote :

Have you clicked "accept changes"?

Revision history for this message
Dirk Herberich (dirk-herberich) wrote :

> Have you clicked "accept changes"?
Yep, I certainly did...

I get the error message after the merge. I have the habit to go back and check both data-sets after the merge. Usually if you merge 2 data sets from the same family tree the second data-set is deleted and all other data-sets linked need to be rewored. That's - i assume - the expected behaviour.
When you merge two data sets from different family trees I assume that both data sets shall remain intact. That seems to happen correctly. But somehow webtrees does not know how to reference to the data set from one family tree to the other. Maybe it's just my understanding as well, and I need to do more manual work.
Kiwi, thanks a million for your fast response.

Cheers,

  Dirk

Revision history for this message
kiwi (kiwi3685-deactivatedaccount) wrote :

I was away from my computer when I first replied, so unable to test your issue. I have done so now, and can confirm your problem.

Whether this is a recent problem, or possibly one that has been there for years I can't say. The merge feature was intended for use within a single family tree, but I did think it worked OK across trees as well. I can't recall anyone ever commenting about actually using it across trees before ;-)

Changed in webtrees:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
fisharebest (fisharebest) wrote :

This code comes from PGV.

PGV allowed you to create links between gedcoms. Hence merging records between gedcoms would create links for the FAMC/FAMS/HUSB/WIFE/CHIL tags.

webtrees does not support links between gedcoms. When you merge records between gedcoms, what behaviour would you expect?

Ignore the links, but copy the other facts?

What else could we do?

Revision history for this message
Dirk Herberich (dirk-herberich) wrote :

Hi guys,

Thanks a million for the fast confirmation of the issue.

> webtrees does not support links between gedcoms. When you merge records between gedcoms, what behaviour would you expect?
- I think the simplest solution would be to remove the functionality to merge across different family trees.
- Well, you asked me what I would expect when merging across 2 trees... Dangerous question ;-). Let me rephrase it slightly to "What I would want", as the implementation of my wishes would be rather complex... I could think of two options, which could even exist in parallel.
a) Functionality to fetch the data missing in familyTreeB a from the familyTreeB records and display these along with familyTreeA, "without changing" either Gedcom (this may require an addition of extra user-defined tags, that could be removed when exporting the Gedcom). To show that the extra info is coming from a different Gedcom file this additional info shall also be highlighted accordingly.
b) Allowing the user to copy missing Gedcom data (missing details for a person, missing persons from a family, etc.) from familyTreeB to familyTreeA, ideally including all missing links, which would mean an auto-copy of missing data into familyTreeA.

I think both my wishes would require very careful thinking before this is implemented and then a very thorough testing campaign after implementation, so I assume that if you plan to do something like what I have suggested this functionality won't be there any time soon.

Please can you let me know what your plans are, so that I can decide what to do with my current Gedcom file. If you plan to drop the merge-functionality across different family-trees I will have to clean up my Gedcom manually, if you decide to alter the current functionality I may wait until you have done so and try again to merge across 2 family-trees.

Thanks again to you all for your great work,

  Dirk

Revision history for this message
kiwi (kiwi3685-deactivatedaccount) wrote :

I must admit I'd never used "merge between two files" for anything other than individuals before, and even then it was only to copy facts, not links. The more I think about it the more it is clearly not practical without a huge new task. The main issue with copying links is simply where to stop? It is likely that EVERY person in a tree is linked, so start copying one link and you will probably end up with them all!

I think in the short term we should completely disable the two-file ability, as that is the easiest fix. Medium term, perhaps we could introduce something that copies just facts / events and not links.

In the long term, as we have said elsewhere, we "might" consider implementing a proper merging tool. But as we know that is incredible hard to do properly.

Revision history for this message
fisharebest (fisharebest) wrote :

<<In the long term, as we have said elsewhere, we "might" consider implementing a proper merging tool.>>

I think the way to start this would be to "append" trees, rather than merge them. We'd need a "renumber" tool to remove duplicates. After that, a merge tool (maybe based on the current one) could be developed.

<<I think in the short term we should completely disable the two-file ability>>

The options are

1) disable completely.
2) merge facts (but not links) when merging between trees.

From a coding perspective, both are equally easy/difficult.

Revision history for this message
Dirk Herberich (dirk-herberich) wrote :

Hi guys,

As I seem to be the only one using this functionality at present I would consider it rather low in priority to get a fix for it. - I have cleaned up my Gedcom manually already, so I am OK from my side.

> I think the way to start this would be to "append" trees
This sounds a very tempting option for me, as the Gedcom that I tried to merge has several connection points where I could just add on...

> 1) disable completely.
> 2) merge facts (but not links) when merging between trees.
> From a coding perspective, both are equally easy/difficult.
From my point of view as a user I would prefer option 2.

As I said: My Gedcom is cleaned up, so I am not in a rush.
Cheers,

   Dirk

Revision history for this message
kiwi (kiwi3685-deactivatedaccount) wrote :

Greg, if both are equally easy/hard, then I would go with 2) as well.

I also agree that "appending" is a good way to start. Combined with the existing merge function it will satisfy a large number of requirements.

Given the low priority etc, I'll mark this as "wish list" for now. Hopefully one of us will have the time at some point.

Dirk - thanks again for you input.

Changed in webtrees:
importance: Medium → Wishlist
Changed in webtrees:
status: Confirmed → Triaged
Revision history for this message
fisharebest (fisharebest) wrote :

Fixed. When merging from different trees, you cannot change the links - they are shown, but are read-only.

Changed in webtrees:
status: Triaged → Fix Committed
assignee: nobody → fisharebest (fisharebest)
Revision history for this message
fisharebest (fisharebest) wrote :

Fix released in webtrees 1.5.0

Changed in webtrees:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.