Default preferred parents messed up upon a duplicate PID being added.
When patrons add a new duplicated person, the preferred becomes set to the new person. The preferred which was previously set to the well established and documented person is usurped and set to the new person which often is erroneous data and will need being merged to the established line. The problem is until it is noticed and merged, the preferred is set to the bad line and when folks do a "First Ancestor", it fails to find the first ancestor.
I suspect right now, the system simply sets the preferred based on the last PID acted upon. Can you instead have the system set the preferred based on the PID with the most sources/memories/collaborations associated with it? As that is most likely to be the well established vetted and correct line?
If you look at the above example, a Patron today added Mattathias ben Amos, and the system set it as the preferred parents. In this case, this PID is the grandparent of the child it was added to. When someone does an "First Ancestor" function it will route down this wrong erroneous line now. Whereas if the preferred had been left assigned to the original and well established correct line, it would work and show path correctly.
I am well aware that I can reset the preferred for me under my profile. However, it remains an issue for many other patrons, many who aren't aware that they can reset the preferred. And when new PIDs are added, MY setting gets nuked and I have to reset AGAIN when I discover it messed up.
Can the code which determines setting the preferred to the latest added PID, be adjusted to evaluate the number of sources/memories and set preferred to the PID with the most?
Also, in the cases where some PIDs can't be merged, I end up choosing to delete the association all together, forcing the system to reset the preferred to the correct parents and thus any patrons who do a "First Ancestor" option, can have success. Meanwhile a unassociated PID is floating around loose in the system.
Bottom line, can the preferred setting upon a new PID being added, defaulting to and staying with the original well established PID, instead of nuking that and assigning it to newer and usually erroneous PID?
Thank you very much! Best regards, LeEric
Answers
-
"Preferred" is a per-user setting. What you do or don't do with it has zero effect on what other people see.
The default -- what you see if you've never visited that profile before -- is affected by edits: when you first visit a profile, the checkmark is on whichever relationship was most recently edited at that point. As far as I know, however, your visit "locks" the setting: once you've been to a profile, further edits do not change the location of the checkmark (unless the edit removes the relevant relationship).
Given that we can't know or predict when people first look at a profile, and given that everyone can change the default, we generally have absolutely no clue where the "preferred" checkmark is for anyone else.
I don't know the reasoning behind using "most recently edited" to determine the initial/default state of the checkmark; I suppose it could just as well be "least recently edited" -- but I'm sure there would be use cases where that would be just as problematic as you're finding the current choice.
1 -
Julia, thanks for your response. I think everything you post confirms what I have suspected. How would we bring this to attention of FS programing staff to see if they could modify things so the primary (as in one with most content) PID becomes the default preferred system wide?
Thanks! LeEric
0 -
@LSMarvin, I cannot parse "most content" applied to different people. The one with the longer name? Or the one who moved around more, and hence has more stuff under Other Information? How would such a method of choosing be of any use to anyone?
The "preferred" setting is meant to pick between different people, not between different profiles for the same person. The latter should be merged: the goal of the collaborative tree is to have exactly one profile per deceased person.
1 -
Julia,
Thanks for the speedy response! The issue is some PIDs can't be merge and end up becoming the preferred by default because it's laying around getting effected by other patrons.
Check out: https://www.familysearch.org/tree/person/details/LVSL-8YF it has a bunch of duplicates which will not merge. Patrons will effect or work on some of these duplicates and it becomes the preferred. And then when patrons run the "First Ancestor" option, it goes awry.
Is there not some way to make the systems default "preferred" stay with the more obviuosly content filled PID? Even when patrons mess with the obviously vacant PID?
I hope this is making sense to you!
I often just dettach the offending PID, put others re-attach them.
0 -
Any connection between that profile and a living person is completely fictional anyway, so what difference does it make which version it defaults to for first-time visitors? (As I've said above, subsequent edits make no difference in the location of the checkmark to a user who has already viewed the profile.)
1 -
@LSMarvin said:
... see if they could modify things so the primary (as in one with most content) PID becomes the default preferred system wide?
Note that the preferred parents or spouse setting is a user-specific setting. Where a person has multiple parents (or spouses), you may choose one set of parents (or spouse) and I may choose another. Your trees will be drawn with your preferred parents (or spouse) and mine will be drawn with mine.
Since preferred relationships are specific to a user, it doesn't really make much sense to talk about a "default preferred system wide," except to the extent that it refers to the choice of preferred relationships for users who have never set it for a particular person in the Tree. I'm not confident that any change in this regard would make many people significantly happier, and it's very easy to make your own choice of preferred relationships if you don't like the current setting.
1 -
Alan, thanks for your responce.
I understand the concept behind my setting my own preferred.
For example, I have selected the "First Ancestor" option in Jesus Christs PID (after setting David and Adam as first) and it fails to find even David, let alone Adam. I have gone throught the genealogy, all way back to Adam selecting the preferred for the actual and bonified working line and then had success, the "First Ancestor" worked. But, as soon as patrons bring in a duplicate (broken) lineage, the option fails. My "preferred" becomes broken.
The very action of a duplicate being added takes prefrence, and becomes the "default" lineage path and also breaks my personally set "preferred".
While I coud be selfish and ask that just the "preferred" aspect be fixed. I'd like to see everyone else helped out and see that the deeper issue is resolved.
0