Infant is continually being added as a spouse to my G grandmother
Since August, there have been numerous people adding the name of Joel Ricks, K2HZ-4WT, who died at 6 months, as a spouse to my G Grandmother, Susette Cardon, KWZL-G15. She was married and sealed to my G Grandfather Joel Ricks Jr, KWZL-G1P. I have put an alert on all pertinent records, I have marked that baby Joel Ricks could not have a couple relationship or children (some are adding my grandmother as his child), but instead of stopping the issue, it seems to be happening more and more. I've called FamilySearch for suggestions multiple times. I've sent a chat to each person trying to find out if they are receiving a hint to create this relationship. No response. I've looked at every source to see if there is something there creating an issue. I haven't found anything. I'm following them so I get notified weekly, but one time I wasn't fast enough to fix it and someone took the names to the temple and sealed them. It appears that either no one sees the notes and alerts or they are using a third party program on their computer that uploads the information. Any ideas?
Answers
-
This search engine creates these confusions with namesakes, but how is it possible to have these seemingly illeterate researchers there... If they are not foreign? This was especially bad in July-August, many people on holidays. Many people only see names... and merge. I kidnapped one Catherine back and added after last name NEVERGERMAN as she was constantly added there. So to stop this search engine I think only the name line works. But that is especially rude - You should mark both, and the other with DIED BABYNEVERMARRIED. How that temple was lucky... they should see to that, that is insulting, you should also report that, they may be blocked also if spreading false information against rules. You need absolutely your family back, or take your tree elsewhere, or try to hide and provatisize them somehow.
0 -
So... I feel like this should be obvious, but PlloN's method almost certainly qualifies as abuse. I don't know what the solution is, but it's not that.
1 -
PiioN is right about one thing: if the collaborative structure isn't working for you, then you should move to an individual-tree structure, either on a different website, or offline.
Adding non-name elements to name fields, on the other hand, is definitely NOT a solution. It just creates yet another problem.
1 -
Actually, what if "Infant" was added as a title? It wouldn't replace the real name, and it wouldn't be within the fields dedicated to the given or family names, but it would make it clear to people that he was, well, an infant. I suppose that it's a bit of a grey area, whether or not "Infant" can be considered a title, but it's the only thing I've come up with so far.
0 -
I have a theory that some desktop genealogy programs that upload/download automatically to FamilySearch is what is creating the problem. I have enough markers on all the records that should prevent this from happening, and it has happened two more times since I posted this question. I think a collaborate tree is fine; but it is ridiculous that it is happening this frequently. I don’t think most people are doing it on Family Tree directly. There has got to be some other reason.
0 -
I just checked the change log and calculated that (since July 2023) at least SEVENTEEN apparently different users have made the same error in attaching Susette Cardon as the mother of an individual who is clearly shown as having died in the year of his birth. An additional three patrons have added children to this relationship.
There appears to be something highly suspicious-looking here and I feel, under such exceptional circumstances, this should be passed to an administrator for investigation. I wonder is there are just two or three individuals involved here who have multiple accounts and are being persistent in their damaging actions?
Perhaps, @Maile L, you could pass this matter to a FamilySearch administrator to do a check. I have experienced something similar, which did become the subject of an investigation, even though the problem was nowhere near to the scale of this example.
I can understand the complete exasperation @HammerLouise1 must be feeling at having this so regularly happen to her relative's profile. Something smells decidedly fishy here, as surely there cannot be so many careless users involved in carrying out the same mistaken addition of a relationship involving the same ID?
4 -
Another observation: They were never attached from the same account twice. Only two of them look like they may be alternate accounts, though that doesn't necessarily mean that they are, or that the others aren't.
0 -
@Paul W thank you for taking this seriously! I feel like it is nearly an abusive situation and I don't understand why it continues to happen. I have called about it SO. MANY. TIMES. with no results. I appreciate your help!
0 -
@BraydenGraves I see you have been active removing baby Joel Ricks. It’s happening almost every day now.
0 -
Perhaps a clue: every single one of those users added an identical marriage event.
The place is always exactly "Salt Lake City, Salt Lake, Ut": lowercase 't' in the state, no country, no background ("standardized") value associated with it.
It seems clear that this marriage is the starting point for all of the ridiculous attachments, but the question remains: where is this marriage listed with this wrong ID? What process or tool are these people using? Whatever it is, it's clearly not showing them anything about what's in the Tree.
I wonder: would an FS employee be able to determine what product/service/tool was used for a particular user's changes? In the many discussions over the years about GEDCOMs, one of the facts that came up is that those imports are only a small fraction of what goes on, but because they're labeled (in the Reason boxes), we users notice them. Other processes do not label their additions, but apparently represent a much greater proportion of imports to the Tree. If FS staff can determine those proportions, then clearly, they have some information about the methods or tools being used; would those details help to track down the source of this inexplicably-recurring error?
2 -
Evil thought: what would happen if you gave up and switched the PIDs? That is, make the baby's profile into Susette's actual husband, and her current husband into the baby? You'd need to replace all of the parents and children and whatnot, but it could be done. Would it stop the cluelessness?
1 -
Is it remotely possible that someone has accidentally made this part of a regular/repeated FT training exercise that uses throwaway logins?
Incidentally, as a user of RootsMagic 8 (which only allows uploads in a very granular manner), and having on purpose set RM up to use a different login to my main one, I can confirm that there is zero on the change log to say that this is an API based change, let alone which 3rd party system it happens to have come from. It would be good to be able to see the provenance of automated changes (obviously this info may be in lower level logs that aren't visible to us).
1 -
I just took a look through the Memories sections of Joel Ricks Jr. and Susette Cardon and wonder why their profiles have not been made read-only, as with other individuals who held such positions within the Church.
This is not a request that can be made by individual users of FamilySearch, but does illustrate the seemingly arbitrary nature of FamilySearch's approach to those profiles that it has been decided should be locked, rather than being fully editable (as in this case).
Regardless, I think this matter still needs further investigation, either for the reasons expressed above (by Julia and Mandy) or to see if there is a connection between the usernames of the (now around twenty) "individuals" who are continuing to add the same ridiculous suggestion that someone who died within months of his birth could be able to marry around eighteen years after his death!
Unless this work is being carried out by some automated process, or one or two users with multiple accounts, how else is this to be explained? Twenty people all making the same careless mistake within a short period of time? Surely, too much of a coincidence.
4 -
Thank you for all the comments. I have been monitoring and nothing has happened since February 11, 2024. Perhaps someone saw this message and was able to go in and fix the problem. I will continue to keep an eye on it, but I'm grateful for the change, by whomever did it.
1 -
FYI, I did some cleanup work for Joel Ricks, K2HZ-4WT. Removed duplicate Sources, etc.
0 -
FYI, I also went to Joel Rick Jr KWZL-G1P (who seemed to be getting mixed up with (K2HZ-4WT) and did cleanup work. FYI, MANY of his Sources were missing Tags - they needed to be reset in order to add Tags back in, which I did.
0 -
It's happening again. I've written to every person who has made the change and I get no response. Is some activities days group using it as practice? How can I get to the bottom of this? It's ridiculous really.
0 -
And again with the identical marriage with the unstandardized place, every single time. I fully agree that it's ridiculous.
Clearly, these people are all working from a single source that associates that 1881 marriage (which is in the IGI a couple of times) with the incorrect PID in the Tree. Equally clearly, they are not being shown anything about what is currently actually in said Tree: they are making these changes completely blind. The Alert Note could be neon orange and blinking; they wouldn't know. The sources and their tags could have loud audio files attached; they still wouldn't know. Whatever mechanism they're using, it is not showing them anything besides that marriage and the opportunity of adding it.
I'm sure you've already tried the "contact us" link under the Help icon, but perhaps it's time to try again? You could present it as following the directions on the "why can't I delete" popup message: you're trying to delete a relationship that never existed. It's somewhat akin to wanting to delete a profile for a person who never existed, right?
1 -
This is abuse of the FT database, whether intentional or not. Surely these users are breaking the Ts and Cs by ignoring the context (if not, maybe the Ts and Cs need tightening)?
Can FS not track the source(s) of this traffic via its low level logs?
Their new AI technologies and skills will hopefully eventually allow them easily to spot, interrupt, and act on this sort of abusive traffic.
In the meantime they could at least block any ip address that is implicated (where are all these single-use accounts being created, I wonder?)
2 -
As suggested on February 9, please would you escalate this matter for further investigation, as it not only very disturbing for @HammerLouise1 but for all regular users of Family Tree. Many of us have underlying worries (possibly quite unfounded) about the security of Family Tree and, in particular, the ease at which it seems our records can be effectively vandalised without any "perpetrator" having to worry about the consequences.
Previously, I have suggested this might be a case of one user having multiple accounts, but I am inclined to think an investigation of this issue should be conducted (by the appropriate team) bearing in mind the comments @MandyShaw1 has made:
(1) Is it remotely possible that someone has accidentally made this part of a regular/repeated FT training exercise that uses throwaway logins?
(2) In the meantime they could at least block any ip address that is implicated (where are all these single-use accounts being created, I wonder?)
This example would be an excellent one for testing out the validity / viability of Mandy's suggestions, and surely this would provide FamilySearch "Security" (or the relevant team) with an excellent opportunity of testing out possible actions / preventative measures that would help in addressing work of this distressing nature.
I wrote above that seventeen apparently different users had made the same "error" in a short period of time - since March 7 a further nine different user names have appeared against the same action. No way can this be pure coincidence (in that totally unconnected individuals are making the same absurd error in adding a spouse to a child who died in the year of his birth).
4 -
FYI I've made reference to this matter on this PQS post: https://community.familysearch.org/en/discussion/158296/flagging-a-change-that-would-decrease-the-quality-score#latest
I've just had another thought: perhaps a 3rd party product has this update in a test script which is accidentally accessing the live database. That would explain the 'Ut' that never changes.
1 -
@Tiffany Farnsworth Nash thanks for all your cleanup work. There was yet again another person creating those relationships this morning. I did write to FamilySearch again and I’m hopeful they will look into it. I’m resigned to checking it multiple times a day now.
0 -
You are very welcome for the cleanup work.
FYI: I changed the wording of the Notes/Alert to all CAPS and and bit stronger wording - but i am doubtful that will help in this situation.
0 -
The people who keep updating it to the ID that belongs to an infant, may be doing so with an electronic sync with a tree they have on either another website or a standalone family history program. They may have added it to their database when it was the ID that was showing married to the mother. If this is the case, then when they update their database and tell it to sync to FamilySearch, it is overriding all the notices, etc - because they aren't manually looking at them when their database is syncing.
They need to update their database to the ID that is correct for the husband and they need to do that manually. They may not even realize they are creating a headache for others. These same users may not even know to check Messages within FamilySearch for communication with you. And they won't be seeing any alert notice. And the system is being overwritten (by a syncing function) where manually it is set to prevent spouses and children to be added.
Perhaps you can see if FamilySearch can make the infant ID a "read-only" ID. Maybe that could prevent the syncing from happening ?-1 -
That sounds plausible, if it was the same user ID making the update repeatedly. And it was my first thought as well. But as @Paul W said above there have been 26 (and counting) IDs making the same incorrect update, and the same ID is not used twice.
It is starting to look like someone, or something, is using single-use throwaway IDs to control the content of FamilyTree. That is not collaboration and is surely an abuse of the system.
1 -
From article at :
In situations like this I believe FamilySearch needs to show some responsibility by investigating how this is happening (whether by some syncing function or not) and try to adopt a way of preventing such abuse of the Family Tree program.
3 -
In my experience it is possible for a 3rd party product to import information in bulk /from/ single or multiple FT profiles to their local database, but going the other way requires a specific request to upload a single new profile or to change a specific piece of information on an existing one. While this latter scenario may well be occurring here, I wouldn't refer to it as 'syncing', which makes it sound far more automated and alarming than I have seen. If there is a product that genuinely syncs bulk information /to/ existing FT profiles, please identify it.
1 -
I don't know if anyone is still looking at this, but I thought I would give an update. FamilySearch, I believe, did some sort of audit on both Joel Ricks (my grandfather) and Joel Ricks (infant). It was discovered that the original PID of my grandfather was inadvertently transferred to the baby Ricks. Probably resulted from an incorrect merge. They reestablished the original PID for the infant and all attempts to add him have stopped. I'm not sure I understand all the technicalities but I'm glad it's fixed! I'm grateful that someone at FS listened and looked into it deeper.
2 -
@HammerLouise1 The FamilySearch reason statement was completely false, and the merges were wrong as well, though they did reveal actual duplicates. (I contacted FamilySearch about that, and they said it was done by an AI.) I had to redo the merges myself to get it correct. I did use the correct merges to change his ID number though.
1
