On PGV 4.2.3 privacy files are set at 90 for "age to assume dead." Previously when running a batch update on missing death records, PGV 4.2.2 would disregard individuals under 90 years. On 4.2.3, the batch update wants to "correct" individuals over 80 years, and I have a LOT of living 80+ year-olds. Is there another "switch" or setting I can change?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-07
Thomas
I'm afraid I don't see that happening on my version.
Can you first double-check your privacy setting (in case you accidentally changed it to 80 -sorry, but have to ask the obvious). then check the GEDCOM data for a couple of those 80 year olds, to be sure that all is correct. Do they have valid birth dates for example? If not, then PGV will be doing some complex calculation using any known information available from other relatives and events that might suggest a reasonable age.
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-07
Just a question to follow up - is 90 a "safe" period to use in order to protect the data of the living? I suspect it will remove protection from quite a large number of living people. Thats why the default is usually 120 years. Better to err on the side of caution, IMHO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have already double-checked the privacy setting. I have double-checked the batch update. I have double-checked the birth dates are in the correct format.
Maybe a person 95 or 110 years old gets their birth date shown, but that's not the issue - we can agreeably disagree on the privacy.
4.2.3 still wants to "Add missing death records" to people born on or after 1920, and as mentioned, I can't use a routine that gives me an excessive number of returns. (This is something in the latest version.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In your first post, you said you have set the MAX_ALIVE_AGE to 90.
In your latest post, you said that people born in 1920 get set to dead. This is 90 years ago. Surely working as designed?
OK, you said "on or after 1920", but you didn't say how much after? 1921? 1999? The code works on whole numbers. There may be rounding errors, and there may be a "<=" instead of a strict "<".
So, how much after 1920. Exactly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K., busted for imprecision. Some dates are: 24 DEC 1921, 28 OCT 1920, 25 JUL 1926, ABT 1920 (of course!,) ABT 1922, 1923, ABT DEC 1925, etc.
I am NOT sure that the privacy settings impact the batch update. It's one of those petty little nuisance problems, certainly not major in itself, but could have greater implications. My privacy setting is NOT "on" & and I am "Showing living names" at this time.
I am addressing the 'Batch Update: Add missing death records' issue ONLY.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The batch update uses the same is_dead() library function that the rest of PGV uses. If it is a problem here, it is likely to be a problem everywhere else - including the privacy/display functions.
Sorry for asking obvious questions (but you need to eliminate the obvious)….
The is_dead() function allows a bit of user customisation, to allow people who died in the last N years to be considered still alive (and hence private).
Have you modified this function in this (or any other) way?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greg: I don't know where that is, or what that is, or am not smart enough to understand the question, SO… I don't think so.
And it doesn't bother me for you to ask whatever…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-08
Thomas
Greg is referring to a setting in Privacy config - "Limit Privacy by Age of Event"
Its help says the following:
LIMIT PRIVACY BY AGE OF EVENT
The Limit Privacy by age of event setting will hide the details of people based on how old they were at specific events regardless of whether they are dead or alive.
Use this setting along with the Age at which to assume a person is dead setting. For example, if you made the Age setting 100 and set this option to Yes, all persons, alive or dead, born less than 100 years ago would be set to private. People who were married less than 85 years ago and people who died less than 75 years ago would also be marked as private. Please note that using this option will slow down your performance somewhat.
From that description I would say its certainly a possible explanation for your issue.
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, the is_dead() function threw me. I have:
"Show living names - to public"
"Age at which to assume a person is dead - 90"
"Limit privacy by age of event - no"
Greg: in the mail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thomas - thanks for this. It makes things so much easier when you can re-create the problem. (FYI I needed to download your gedcom to my dev machine, but have now erased it from my hard disk. You can delete the admin account you gave me).
It is a bug in the is_dead() function, which I have just fixed in SVN.
Line 245 of functions_privacy.php refers to "$childrec", when it should refer to "$grandchildrec". Thus it was using grandchild logic on child dates.
Unfortunately, PGV keeps a record of the "is dead" calculations, so you may have people wrongly marked as dead, and hence public. The easiest way to reset this is to use SQL to update all rows in the i_isdead column of the pgv_individuals table to -1.
If SQL is too much for you, then simply export and re-import the gedcom.
Greg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can this fix be applied directly to the 4.2.3 release as it would seem to be pretty important in privatising living people?
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-09
Mark - I can't answer your question directly, but my understanding is that a re-release (I think thats what you are asking for) is a big job. The usual alternative is to put a new file in Patches here.
But I'm not sure its all that critical. It takes fairly unique circumstances to trigger it. I believe it would only appears as a problem when PGV has exhausted all previous attempts at assessing "is dead?". Starting with the obvious - the birth of the individual, then other events in that individual's life, then the individuals parents birth dates, then spouse birth dates, then children's birth dates, then finally the one with the bug, check for grand-children's birth dates.
I haven't seen Thomas' GEDCOM, but it would seem there is a lot of information missing that would not only be valuable to have, but also allow PGV to run much more efficiently. I was unable to replicate the problem on my system, but I tend ,whenever possible at least, to put in EST or CAL dates if I have nothing else.
Nigel
So Thomas must have had (as I understand the code) individuals where the person had no birth, no parents birth, no spouse birth, and no children's births to use as "proxies" for age.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was more thinking of a one-for-one replacement file so that other SVN changes aren't applied.
I've actually done the one line change to fix the bug, done the SQL and pulled up the All Individuals for each GEDCOM and watched the -1's change to 0's and 1's in the table. So I'm happy enough.
I tend to use a lot of 1 DEAT Y to avoid lengthy calculations when I have little data for obviously deceased people.
I'm sure I also have people where I have no birth date, no parents birth or marriage dates, no grandparents birth or marriage dates, but there is not a quick fix to say "alive". So I was wary that I would run into this bug too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<QUOTE>So Thomas must have had (as I understand the code) individuals where the person
had no birth, no parents birth, no spouse birth, and no children's births to
use as "proxies" for age.
I don't open my site yet to public so this isn't an issue. However, I have tons of entries w/o any dates of parents, individuals, siblings or anyone else that would give me a clue as to whether they are living. So, it's not unique. It's why I don't go "public". It'll be many more rounds of edits before I can gain any insight as to living state, if ever.
So too, some of my Sources, be what they are, refer to the individual as "living". But the last update was say 10 years ago. I have no idea how old they were then so no idea if 10 years later they're still alive.
All that said, if I would have same problems. I decided not to use the Batch update because of this and am going through manually, while doing other edits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works far better now, identifying some others born 1845, etc.
I not entirely sure we're QUITE there yet. "Batch Update: Add missing death records" want to update the following record:
0 @I4065@ INDI
1 NAME Bettie E /Perkins/
2 GIVN Bettie E
2 SURN Perkins
1 SEX F
1 BIRT
2 DATE ABT DEC 1925
2 PLAC Lyda, Macon, Missouri, USA
1 FAMC @F1483@
1 CHAN
2 DATE 07 JAN 2008
3 TIME 17:54:32
1 DEAT Y
Another reads:
1 BIRT
2 DATE 02 JAN 1924
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-09
But the first of those two example already has a "1 DEAT Y" tag. Are you saying Batch Update is trying to add a second DEAT tag?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rats! (Caught being imprecise again.) No, sorry, the "1 DEAT Y" is the part in red that the batch update WANTED to add.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-02-10
No worries Thomas. I half suspected that might be the case.
Next silly question - did you follow Greg's advice and amend the is-dead record in your database:
Unfortunately, PGV keeps a record of the "is dead" calculations, so you may have people wrongly marked as dead, and hence public. The easiest way to reset this is to use SQL to update all rows in the i_isdead column of the pgv_individuals table to -1.
… and one other really silly question - your web server does have the right year I assume? It doesn't 'think' its 2015 now or something does it?
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On PGV 4.2.3 privacy files are set at 90 for "age to assume dead." Previously when running a batch update on missing death records, PGV 4.2.2 would disregard individuals under 90 years. On 4.2.3, the batch update wants to "correct" individuals over 80 years, and I have a LOT of living 80+ year-olds. Is there another "switch" or setting I can change?
Thomas
I'm afraid I don't see that happening on my version.
Can you first double-check your privacy setting (in case you accidentally changed it to 80 -sorry, but have to ask the obvious). then check the GEDCOM data for a couple of those 80 year olds, to be sure that all is correct. Do they have valid birth dates for example? If not, then PGV will be doing some complex calculation using any known information available from other relatives and events that might suggest a reasonable age.
Nigel
Just a question to follow up - is 90 a "safe" period to use in order to protect the data of the living? I suspect it will remove protection from quite a large number of living people. Thats why the default is usually 120 years. Better to err on the side of caution, IMHO.
I have already double-checked the privacy setting. I have double-checked the batch update. I have double-checked the birth dates are in the correct format.
Maybe a person 95 or 110 years old gets their birth date shown, but that's not the issue - we can agreeably disagree on the privacy.
4.2.3 still wants to "Add missing death records" to people born on or after 1920, and as mentioned, I can't use a routine that gives me an excessive number of returns. (This is something in the latest version.)
Thomas - am I missing something?
In your first post, you said you have set the MAX_ALIVE_AGE to 90.
In your latest post, you said that people born in 1920 get set to dead. This is 90 years ago. Surely working as designed?
OK, you said "on or after 1920", but you didn't say how much after? 1921? 1999? The code works on whole numbers. There may be rounding errors, and there may be a "<=" instead of a strict "<".
So, how much after 1920. Exactly.
O.K., busted for imprecision. Some dates are: 24 DEC 1921, 28 OCT 1920, 25 JUL 1926, ABT 1920 (of course!,) ABT 1922, 1923, ABT DEC 1925, etc.
I am NOT sure that the privacy settings impact the batch update. It's one of those petty little nuisance problems, certainly not major in itself, but could have greater implications. My privacy setting is NOT "on" & and I am "Showing living names" at this time.
I am addressing the 'Batch Update: Add missing death records' issue ONLY.
The batch update uses the same is_dead() library function that the rest of PGV uses. If it is a problem here, it is likely to be a problem everywhere else - including the privacy/display functions.
Sorry for asking obvious questions (but you need to eliminate the obvious)….
The is_dead() function allows a bit of user customisation, to allow people who died in the last N years to be considered still alive (and hence private).
Have you modified this function in this (or any other) way?
Greg: I don't know where that is, or what that is, or am not smart enough to understand the question, SO… I don't think so.
And it doesn't bother me for you to ask whatever…
Thomas
Greg is referring to a setting in Privacy config - "Limit Privacy by Age of Event"
Its help says the following:
LIMIT PRIVACY BY AGE OF EVENT
The Limit Privacy by age of event setting will hide the details of people based on how old they were at specific events regardless of whether they are dead or alive.
Use this setting along with the Age at which to assume a person is dead setting. For example, if you made the Age setting 100 and set this option to Yes, all persons, alive or dead, born less than 100 years ago would be set to private. People who were married less than 85 years ago and people who died less than 75 years ago would also be marked as private. Please note that using this option will slow down your performance somewhat.
From that description I would say its certainly a possible explanation for your issue.
Nigel
I can't reproduce this on my site, nor can I think of something that might cause it.
If you can give a temporary admin account (I promise just to look and not change anything), I'll be happy to investigate further.
Sorry, the is_dead() function threw me. I have:
"Show living names - to public"
"Age at which to assume a person is dead - 90"
"Limit privacy by age of event - no"
Greg: in the mail.
Thomas - thanks for this. It makes things so much easier when you can re-create the problem. (FYI I needed to download your gedcom to my dev machine, but have now erased it from my hard disk. You can delete the admin account you gave me).
It is a bug in the is_dead() function, which I have just fixed in SVN.
Line 245 of functions_privacy.php refers to "$childrec", when it should refer to "$grandchildrec". Thus it was using grandchild logic on child dates.
Unfortunately, PGV keeps a record of the "is dead" calculations, so you may have people wrongly marked as dead, and hence public. The easiest way to reset this is to use SQL to update all rows in the i_isdead column of the pgv_individuals table to -1.
If SQL is too much for you, then simply export and re-import the gedcom.
Greg
You're my hero (again.) ;-)
Can this fix be applied directly to the 4.2.3 release as it would seem to be pretty important in privatising living people?
Mark
Mark - I can't answer your question directly, but my understanding is that a re-release (I think thats what you are asking for) is a big job. The usual alternative is to put a new file in Patches here.
But I'm not sure its all that critical. It takes fairly unique circumstances to trigger it. I believe it would only appears as a problem when PGV has exhausted all previous attempts at assessing "is dead?". Starting with the obvious - the birth of the individual, then other events in that individual's life, then the individuals parents birth dates, then spouse birth dates, then children's birth dates, then finally the one with the bug, check for grand-children's birth dates.
I haven't seen Thomas' GEDCOM, but it would seem there is a lot of information missing that would not only be valuable to have, but also allow PGV to run much more efficiently. I was unable to replicate the problem on my system, but I tend ,whenever possible at least, to put in EST or CAL dates if I have nothing else.
Nigel
So Thomas must have had (as I understand the code) individuals where the person had no birth, no parents birth, no spouse birth, and no children's births to use as "proxies" for age.
I was more thinking of a one-for-one replacement file so that other SVN changes aren't applied.
I've actually done the one line change to fix the bug, done the SQL and pulled up the All Individuals for each GEDCOM and watched the -1's change to 0's and 1's in the table. So I'm happy enough.
I tend to use a lot of 1 DEAT Y to avoid lengthy calculations when I have little data for obviously deceased people.
I'm sure I also have people where I have no birth date, no parents birth or marriage dates, no grandparents birth or marriage dates, but there is not a quick fix to say "alive". So I was wary that I would run into this bug too.
<QUOTE>So Thomas must have had (as I understand the code) individuals where the person
had no birth, no parents birth, no spouse birth, and no children's births to
use as "proxies" for age.
I don't open my site yet to public so this isn't an issue. However, I have tons of entries w/o any dates of parents, individuals, siblings or anyone else that would give me a clue as to whether they are living. So, it's not unique. It's why I don't go "public". It'll be many more rounds of edits before I can gain any insight as to living state, if ever.
So too, some of my Sources, be what they are, refer to the individual as "living". But the last update was say 10 years ago. I have no idea how old they were then so no idea if 10 years later they're still alive.
All that said, if I would have same problems. I decided not to use the Batch update because of this and am going through manually, while doing other edits.
<<Can this fix be applied directly to the 4.2.3 release>>
Yes - it is a simple one-line edit.
If someone wants to create a patch, and write instructions for re-importing / updating-sql, please do.
It works far better now, identifying some others born 1845, etc.
I not entirely sure we're QUITE there yet. "Batch Update: Add missing death records" want to update the following record:
Another reads:
But the first of those two example already has a "1 DEAT Y" tag. Are you saying Batch Update is trying to add a second DEAT tag?
Rats! (Caught being imprecise again.) No, sorry, the "1 DEAT Y" is the part in red that the batch update WANTED to add.
No worries Thomas. I half suspected that might be the case.
Next silly question - did you follow Greg's advice and amend the is-dead record in your database:
… and one other really silly question - your web server does have the right year I assume? It doesn't 'think' its 2015 now or something does it?
Nigel
The sever says it's
, and no, I did not reset the is_dead, and really don't think I have any of those.