export households from ward directory?

[russellhltn]

I have only seen speculation on the part of forum commenters that, in their opinion, "meetinghouse" policy should be construed to regulate leaders' use of "third party software" for that purpose on their own computers.

No, I'm not suggesting that it limits in any way what software you can use on your computer. I'm saying it limits what software can be used to handle the church's data.

We've discussed elsewhere the difference in security risk between programs that are generic data handlers (like Excel) compared to non-church sponsored programs that "understand" the data. Usually in the context of third-party servers.

[RossEvans]

I have only seen speculation on the part of forum commenters that, in their opinion, "meetinghouse" policy should be construed to regulate leaders' use of "third party software" for that purpose on their own computers.

No, I'm not suggesting that it limits in any way what software you can use on your computer. I'm saying it limits what software can be used to handle the church's data.

We've discussed elsewhere the difference in security risk between programs that are generic data handlers (like Excel) compared to non-church sponsored programs that "understand" the data. Usually in the context of third-party servers.

There you go again with speculation, what commenters here think a policy or good practice ought to be. More forum folklore. I am concerned with what the new Meetinghouse Technology Policy actually says, and I see absolutely nothing that applies to leaders' own personal computers. The deeper we analyze the current documents, all we find with respect to "third party software" is policy regarding church computers in meetinghouses.

[russellhltn]

The fact remains that the Meetinghouse Technology Policy that came out this month says "4.8.3 The use of MLS data and membership information in third party software is prohibited."

We can disagree on if this is binding on only church machines or not. Hopefully, in due time we'll get a clarification.

[elmerohueso]

I have been asked to post the following statement, approved by a manager at Church headquarters with responsibility for products such as the Directory on LDS.org. I hope this will help clear up some of the questions that have been raised in this discussion.

The Church has to be careful about following privacy laws in many different jurisdictions. Because of this, the Directory on LDS.org has been changed so that only clerks, bishopric members, and stake presidencies can access the Export Households functionality. The issue is that once data is exported, the Church no longer controls the data. The Church then becomes legally liable when it has provided a way for data to be exported. Similar data export changes are also being made in LDS Maps and MLS. When other ward and stake leaders need access to lists of members for their callings, they should contact their ward or stake clerk.

So, they're just trying to make it harder to get an exported list, if you can still get it from a clerk. It's really not solving any problems, and will just make things more difficult for members (and clerks, who will be getting more requests for exported data).

[jwolley]

Online help on this (https://ue.ldschurch.org/ldsapphelp/dir ... orting.htm) still says "1.In the left sidebar, click Export Households." - but that option is no longer there - can someone please restore it? Thanks...

[russellhltn]

Online help on this (https://ue.ldschurch.org/ldsapphelp/dir ... orting.htm) still says

The help files are slow in getting updated.

[rich]

I see in LUD [Export Households] and indeed a file 'unit#.csv' is exported. The schema is very different from MLS though.

Where is the MLS schema (fields) for geo-coding member lists in LDS.Org?

As a clerk, I use the MLS ward and stake geo-codes to track Spanish/English households and other attributes my unit leaders have requested be tracked. Without seeing/setting geo-codes, LDS.Org member list exports are less functional for a clerk.

[eblood66]

I see in LUD [Export Households] and indeed a file 'unit#.csv' is exported. The schema is very different from MLS though.

Where is the MLS schema (fields) for geo-coding member lists in LDS.Org?

As a clerk, I use the MLS ward and stake geo-codes to track Spanish/English households and other attributes my unit leaders have requested be tracked. Without seeing/setting geo-codes, LDS.Org member list exports are less functional for a clerk.

Those codes are not stored in the databases at CHQ. So they aren't available from lds.org in any form or by any mechanism. You have to use MLS for reports that include the Geo Code fields.

[rich]

I partially agree/understand that they aren't available in LDS.Org. From my experience geo-codes are received/sent from/to CHQ all the time.

Example: when I receive a new record in my unit, CHQ often has the geo-codes set to some value that means something to them or the previous unit the record came from. Also when I change a geo-code locally in MLS, do a [Send/Receive Changes], the change is confirmed in a CHQ record update response. Whether it's actually stored at CHQ and would be recovered if I did a [File][Request Unit Refresh Data...], I can't say for sure. I suspect the geo-code values set locally would be recovered though.

[eblood66]

I partially agree/understand that they aren't available in LDS.Org. From my experience geo-codes are received/sent from/to CHQ all the time.

Example: when I receive a new record in my unit, CHQ often has the geo-codes set to some value that means something to them or the previous unit the record came from. Also when I change a geo-code locally in MLS, do a [Send/Receive Changes], the change is confirmed in a CHQ record update response. Whether it's actually stored at CHQ and would be recovered if I did a [File][Request Unit Refresh Data...], I can't say for sure. I suspect the geo-code values set locally would be recovered though.

Geo Codes are transmitted from the ward to the stake which is why you see the change confirmed. But I'm pretty sure they are not stored in the CMIS (the membership database).

I've not heard of records coming with a geo code. That would make it hard for units to know which records need to have the geo code field set according to local standards. But I've never actually used geo codes so I can't say from experience anything about that. Perhaps others can comment.

This is really a different topic so I expect a moderator will move these posts to a new thread.