Mikerowaved wrote:That might not be true in all cases. Ward members can request a Ward list from someone with access to the MLS computer, but they can't get these themselves. Whether this is to be given out should really be under the direction of the local Unit leadership. The LUWS on the other hand, IS available for all Unit members to print a roster from at anytime.
I maintain our LUWS and a couple of times a year also print a Ward directory to distribute to the general membership. This directory (and the LUWS) have several exclusions that the Bishop has made known to me of members that do NOT wish to be included in any published Ward list. Technically, Unit lists that are published are supposed to include ONLY those that have given their consent to be on it. (I wish I can remember where I read that.) We fudge that a little by removing those who so request it.
I am not trying to belittle your efforts, or your program. I think it's a great script. I'm just trying to point out that if you use MLS as your source, then it runs the risk of including some individuals that might not wish to be included and somehow we must respect their wishes.
Wouldn't this all be a LOT simpler if MLS included a flag, like LUWS does, to exclude certain members from a simple Ward List? (Hint, hint!)
I am coming to the conclusion that I made a flawed design decision in basing the Family KML output only on the MLS extracts.
My intention was to produce a simple output file that could be distributed to all members with no questions asked, but I failed to understand all the unwritten policy nuances and local variations. Perhaps I will write a different module that is driven primarily by the LUWS file to select the set of familiies that populate a KML file. (I think I would have to require it to be a subset of the MLS universe of families, which would still drive the master geocoded table of addresses. So an address that was not in both the LWUS and MLS extracts at the point in time where MakeKML runs would just not appear in the new file.)
With that caveat, the new file could be distributed to all in the ward without concern because it would include no information not in LUWS. I would name the new file <UnitName>WebSiteFamilies.KML. It would be an additional or alternate output. I suspect there are lots of wards that are like mine and would prefer the output as-is. So I would keep <UnitName>Families.KML, too.
I don't know how long it will take me to write and test that new module -- probably not that long, except my day job and real life limit the time I can invest.. If the church releases its own member-mapping application on LUWS very soon, I might not bother.
I did not realize that it was common practice in other wards to enforce manual edits on standard MLS outputs such as ward directories. (I've clerked in two wards a decade apart, using MIS and MLS, and this was a new one on me.) If this is common practice, and bishops do have this requirement, I think it is pure madness that MLS does not support the need with suppression functionality built-in. It is elementary that the design of custom software such as MLS should be driven by the "business rules" of the organizations that use them. Apparently the designers of MLS flubbed that one. But MLS is what it is.
For users of my scripts, my instructions would be this for wards that have a suppression requirement:
1) If and when I get the new module written and released, the easiest thing for you to do will be to discard <UnitName>Families.KML and distribute <UnitName>WebSiteFamilies.KML instead. (Meanwhile, until I get around to creating such a file, this is not an option. What is an easy option is not distributing a general families KML file at all, limiting is distribution to leadership, or choosing not to run these scripts.)
2) If you do want to distribute <UnitName>Families.KML and must edit the content,
do not edit the MLS extract files. You risk breaking the scripts if you do.
Instead, let the scripts run and load the results into Google Earth, make your edits there, and save the edited KML files for distribution.
If, like Mikerowaved, your ward's practice would be to produce a directory twice a year by manual edits, updating the KML file to match would not be that burdensome. You would just have to make your edits in two places. If, however, you have a lot of turnover like our ward does (we plan weekly updates) the feasibility of this gets shakier. (Heck, if I only cared about biannual updates, I would scrap the Yahoo geocoding and spend 50 bucks a year to get the edited files commercialy geocoded with superior quality and fewer exceptions to deal with.)
A note about internal table-handling of the MakeKML.vbs script: It already aborts at certain places if there are obvious signs that the MLS extract files have been altered, to protect against undefined results. Now that I understand there is a propensity for users to edit the MLS extract files, in future releases I will probably try to lock down the files and queries even more. I can't make the script bulletproof, but I will try to make it idiot-resistant. Meanwhile disregard the instructions above at your own peril.