I can’t find a statement of the logic of what What’s New is actually listing.
Re imported records (whether straight from FS to RM, or via Legacy), it seems to list a lot of records with absolutely no recent history on the Changes button (or on FS itself).
Also, if I look at an entry on the What’s New list, whether or not I edit the RM record the list entry then seems to disappear - is this how it’s designed to work?
Finally, and separately, I frequently see Not Matched coming up with a minus value, what does this mean?
Thanks.
Sometimes What’s New is tickled when FamilySearch is working on the backend. It could be a collection you have connected to someone, or a number of other things. So it is not unusual to see nothing visually different.
The negative Not Matches has been seen at times. Not really sure what causes it. Possibly people deleted off FS you had been connected too?
Yes, I have also seen that – not any changes.
Renee:
With Not matches, maybe you should have a look at http://support.rootsmagic.com/hc/requests/127726 that I have with Jackson where I have used the UnMatch to take out the FS side. I have also seen other persons that are blue at the FS side.
I looked at that ticket and I agree with Jackson. You need to use UnMatch on those that come up with the wrong match. It’s hard to say who may have merged what to have the wrong person show up.
Re What’s New, I have done some more research on the false positives.
I looked at the FamilySearch Person JSON for one example, and found this in sourceDescriptions, in the high level citation to (as opposed to from) the Family Tree:
“value” : “"Family Tree," database, FamilySearch (http://familysearch.org : modified 06 September 2023, 14:17), entry for Nathaniel Wood (PID FamilySearch.org ); contributed by various users.”
(my bold)
If you use the second embedded link you can see that this person’s FT entry has not been updated since 16 Jan 2021, and that the Sources have not been updated in any way since 20 May 2022 (this is backed up by all the timestamps on the relevant JSONs, other than the one for the high level FT citation just mentioned).
This updated high level FT citation doesn’t appear anywhere on the FS UI that I can identify, nor is it in RM anywhere that I can find, so I can’t check it any other way.
So, why did this citation date appear to change out of the blue, I wonder? It looks to me as if this is the source of the false positive - clearly it may result from backend activity, as you suggested, but I asked about it on the FamilySearch Community and was advised that I might get on better asking here!
This of course also begs the question, why does RM count a Person as changed, and thus produce a false positive, when all that has been updated is a citation that it doesn’t even appear to use anywhere?
It’s not a false positive. I can see where that person was modified on 6 Sep 2023. Not everyone has access to all portions of FamilySearch. Sometimes what has been updated has restricted access. It’s on the backend.
Ah OK, thanks, but if that value doesn’t affect RM, why does RM treat it as an update? Perhaps RM has no way of differentiating?
People are placed on the Changed List when the timestamp they were last viewed in the FamilySearch Person Tools is earlier then the last update was made on FamilySearch. We have no way of knowing what was changed just that FS shows it was updated since you last viewed the person. So there isn’t any way for us to filter them.
Many thanks Renee, this is v helpful.
Are you able to advise what the fsVersion column in familysearchtable holds (I’m accessing this via the SQLite RM tools)? fsVersion clearly informs, and is populated by, the What’s New function, but it would be good to understand what its detailed content represents.
No, I’m not sure on that.
I think I have now got to the bottom of fsVersion’s content.
If you extract the ‘version’ value in the FS Person JSON (this being unique for a Person, and specific to the ‘to’ citation for this Person’s Family Tree entry), fsVersion always matches the following formula:
(version+12219292800000)*10000
except for the rightmost digit of fsVersion (which is almost always zero, but occasional values of 1-4 appear in my data).
The FS Person ‘version’, which is clearly (like other FS timestamps) a Unix timestamp extended to the right by 3 digits, does not (from my analysis) always indicate the latest date/time for this Person as a whole; conversely, as Renee has shown, it may represent a change in the FS back end that we cannot see; but it definitely appears to me (for RM8) that the logic for populating fsVersion is as I have just given it (tested against c.600 Persons with a 4 year range of ‘version’ timestamps).
2 Likes