A prime example of a problems with the Living Flag was discussed earlier today on the E-mail list, and that discussion got me to thinking whether there might be a better way to manage the Living Flag that would cause fewer problems for users. I think I've come up with a fairly simple solution - much simpler than the way the Living Flag works today. I'm going to write it up, and if it stands up to scrutiny I'll re-post this proposed solution to the Wish List in a few days.
First of all, I think it's important to rename the flag. A rose by any other name would smell as sweet, but nevertheless names are important. I think that renaming the flag to be the Privatize Flag makes it more clear what the function of the flag is, and will help to frame our thinking about how the flag should work.
Second of all, let's think in terms of throwing out completely the existing logic for Living Flag and start over from scratch. I think the existing logic is just too flawed to be repaired, and sometimes a fresh start can be the best approach. To that end, let's pretend the logic for the Living Flag didn't exist, and let's pretend we were designing a new feature called the Privatize Flag that would appear in RM4 in December 2011. Here is how I think it should work.
We would need a way for users to populate the new Privatize Flag for every individual in our database. There should be an option accessed as Tools->Privatize to bring up a dialog to set the Privatize Flag. The dialog would not use the Find Dialog with RM Explorer at all. Rather it would work as follows. A dialog box would pop up that would say something like the following.
Privatize everyone in the data base except for * Individuals with a Death Fact and * Individuals with a Birth fact before _____The only actual option specified by the user would be the year (not the month/day/year) that would be compared against each Birth Fact. The presence of any Death Fact, no matter when the Death Date, no matter if the Death Date is blank, and no matter how malformed the Death Date might be, would prevent the individual from being privatized. The presence of a Birth Fact with a valid date before the date specified by the user would prevent the individual from being privatized. So a Birth Fact with a blank Birth Date or with a malformed Birth Date would have no impact on the privatize decision. In the case of multiple Birth Facts each with a valid date, only the latest date would be used to make the privatization decision.
The logic would specifically use the Birth Fact and the Death Fact and not the Birth and Death dates from the PersonTable. Absent the use of SQL, users can's see the Birth and Death dates from the PersonTable directly except that the Birth date from the PersonTable is visible in the Index Sidebar. The dates from the Index Sidebar can't be trusted to make privatization decisions, so the dates from the Birth Facts and presence of Death Facts must be used instead to make privatization decisions.
Of course, Tools->Privatize could be run at any time, not just once after installing the new feature were delivered by the RootsMagician.
I'm trying to keep this proposal as simple as possible, but there is one useful complication that I want to add. Namely, all of a given individual's ancestors are known to have been born before the individual. Therefore, if a given individual has a birth date that is early enough that the individual need not be privatized, then the same is true of all the individual's ancestors, no matter what the Birth Facts for the ancestors might say. And sometimes ancestors may not even have Birth Facts, but we still don't want to privatize them when one of their descendants has an early enough Birth Date.
Therefore, the internal logic used to implement Tools->Privatize command should be as follows.
- Set the Privatize Flag on for every individual in the database.
- Process every individual in the database a second time as follows
- If the Privatize Flag is off for an individual, perform no additional processing for the individual. The reason the Privatize Flag would be off at this point in the process would be because one of the individual's descendants has already been encountered who has a birth date early enough not to require privatization.
- If the Privatize Flag is still on for an individual, turn off the Privatize Flag for the individual if there is a Death Fact for the individual or if the latest valid date from the collection of zero or more Birth Dates for the individual is before the date specified by the user; and turn off the Privatize flag for all direct ancestors of the individual if the latest valid date from the collection of zero or more Birth Dates for the individual is before the date specified by the user.
As far as the logic of printing reports, creating Web pages, exporting GEDCOM, etc., the logic would remain exactly as it is now except that the Privatize Flag would be tested instead of the Living Flag and the dialog boxes would be adjusted to reflect the "Privatize" terminology instead of the "Living" terminology.
I'm tempted to stop at this point, and simply declare that users need to do a Tools->Privatize occasionally, and in particular before any report they run. The following logic gets a little more complicated to describe, but it also would probably be useful for RM4 to run a Privatize operation internally and automatically on any individual when that individual is added to the database or edited. To that end, the date specified in the most recent Tools->Privatize for the entire database would need to be saved for the use of the internal and automatic Privatize operation. And in addition, the internal and automatic Privatize operation for an individual would need to process all the direct ancestors of that individual as described above.