Abe's family

ahh, I got your back Mr. President.

Please check the Geni logs.
We have a general problem with people sabotaging lines by using their Pro rights to cut connections without a trace.

If not having any logs on cutting connections I urgently ask you to add some.

Anyhow, - it looks like you have not yet fixed the error I have reported several times. If you merge in a profile which results in getting a new Added By because that person added the profile before the one listed in the main profile, Geni just wipes out the primary manager as well and delete the main profile or simply make it totally unconnected. Knowing the history about that profile it would be impossible for the current manager to be the primary manager unless there is an error in Geni.

I support Bjørn's comment about that error / bug in Geni. It has happened to me several times, most recently a couple of days ago, where profiles of two cousins (husband and wife) suddenly got deleted in the middle of a merge. Because I wasn't the primary manager, I couldn't retrieve them from deleted profiles. I ended up recreating them, and trying to explain to the original primary manager what had happened.

master profiles should not be able to be disconnected from their master profile parents. the connections need to be locked and permanent. and master profile parents should always be the default parents shown.

I have only personally experienced this bug with profiles that are not MPs.

But if MPs are not locked, they can presumably be edited by collaborators (or family members if they are private), just like any other profile.

It IS a bug in Geni because when they get deleted they just leave a black hole in the tree leaving all connections intact to an unknown profile placeholder.

It is technically impossible for a user to delete a profile that way.

The bug is as simple as that the wrong profile get deleted when Geni switches Added By ID.

Yes it is a bug as Bjørn describes it. I don't think anyone in this discussion has disagreed with that.

[#LAD-118190]: Elizabeth II deleted
http://forum.geni.com/topic.php?id=70531&replies=16#post-629371

Brox the reason we haven't been able to fix the bug as reported, is that we cannot reproduce it according to your description. The best way to get a bug fixed is to provide step-by-step instructions for reproducing it. Here's what I tried, but had no problem:

1. Start a tree as user A, add and invite two brothers B and C.
2. Add sister D.
3. B joins.
4. C joins, adds sister E and adds B as a manager (B accepts the request)
5. C merges D and E -- E becomes the head profile after the merge because it has more managers, but Added By credit goes to A, because D was created first.
6. C resolves the data conflict to choose a first name.

This all worked just fine for me, no deleted / disconnected profiles. Do you have any suggestions as to what piece of the puzzle is missing?

Michael, I also have not been able to reproduce the bug on demand, but the bug does exist. I know that might not help you fix it!

It has mostly happened on profiles with a lot of managers, so you might have a timeout issue here as well. Another observation is that is is mostly profiles from 2007 that causes this. Can it be profiles flagged in some way, like profiles that should be released because of inactivity.

In any case: Isn't it easier to detect that the wrong profile (i.e the main multi-manager profile instead of the one that get merged in) is disconnected or deleted?

I have experienced the bug with family profiles (third / fourth cousins), not profiles with a lot of managers. I wondered whether in my case the bug related to being right on the edge of the set of private profiles that I could work with (just within family at fourth cousin level) as against just outside (fourth cousin once removed). I thought maybe my cases related to some access bug on that boundary, such as when children are within "family" but parents aren't or vice versa.

Brox I've got code specifically to make sure the profile being deleted is NOT the head profile of the merge, yet this thing still manages to sneak past somehow.

David I believe the deletion occurs when resolving conflicting data -- in that case, it shouldn't depend at all on nearby family relations or even whether the profile itself is within your Family Group range. If you have permission to edit the head profile, then you have permission to resolve the data conflicts.

Michael: As you know well, what should happen and what actually happens are not always the same thing. My issues arose during the merge itself, not during resolving conflicting data. Maybe the bug I have experienced is not the same as the one that Bjørn experienced.

Mike, - isn't the situation I describes that because of the change of Added By manager from the second profile causes a focus on a new head profile internally?

In all situations I have seen so far you get both a new Added By and a Managed By when this happen, usually totally inactive Geni users.

David, it sounds like your bug is different. Do you happen to know the profile IDs that got deleted in the middle of your merge? Or do you recall when it happened, within a couple hour timeframe?

Bjørn I'm not sure I understand you, but the business of granting "Added by" credit to the creator of the older profile even if it's not the primary after the merge, is as simple as something like "head_profile.added_by = merge_profile.added_by if merge_profile.created_at < head_profile.created_at" -- there's nothing tricky about it.

I just wanted to focus on the fact that you also get a new primary manager, usually a manager from an inactive account, and that is what make me suspect that there is a focus switch somewhere.

Bjørn, that is unusual.. I'd have to see an example of that so that I could maybe discern where this manager came from. I thought you all were saying that primary management is incorrectly being assigned to the manager of the profile that is being merged in, rather than the manager of the profile that comes out on top after the merge.. but maybe that's not the case?

The new manager is not the one that get inserted as the Added By, .- it is usually the next in line depending on whatever the criteria is. Sometimes the original primary manager is totally removed as the manager, which resulted in my first theory in the forum discussion that the removal of multiple listing as a manager fails (which is however true if you get a focus change).

If the profile get unconnected or deleted is the same error. I don't know how the internals look like, but I assume that a profile that get placed in a data resolve queue is will get all connections to it's position in the tree cut, and when the data conflict is resolved that profile will be deleted. If you some place get a focus switch the main profile will get deleted or just disconnected depending on if you get a deta conflict or not, but might be later on be deleted when the data conflict is resolved.