Ward Area Book

Hello,

Each quorum or organization in our ward council is always focusing on several individuals throughout each week. However, ward council meetings would take hours if we reviewed each of these individuals or families. Instead, our ward council meetings revolve around a couple of families or individuals that a quorum or organization needs assistance with. We found that it is much easier to share all of this information we gather about members and investigators in what we call our "Ward Area Book." Any visits or attempts to contact families are recorded in the area book by any member of the ward council. This way you can look up a family or investigator and see a running story of interactions with the ward. Additionally, it is a way to return and report without having to spend all of the ward council meeting time reviewing reports.

I have made it easy for any ward to create their own area book for free for any ward council to utilize. Each member can establish their own username and password and request access to your ward's area book. Additionally, it allows clerks and bishoprics to sync the area book with information from MLS quite easily, showing what changes exist between the area book and MLS, allowing the ward council to update member info in the area book, giving clerks a notification to update it in MLS as well.

I realize that it is in the infant stages still, but I would love to hear feedback and get some input on how to make the ward area book more effective for ward councils. You can start an area book for your unit at https://www.ldsareabook.org

Best,

Topher Reynoso

topherreynoso wrote:Additionally, it allows clerks and bishoprics to sync the area book with information from MLS quite easily, showing what changes exist between the area book and MLS, allowing the ward council to update member info in the area book, giving clerks a notification to update it in MLS as well.

Nice idea, but note that we've been instructed in this forum not to upload data from MLS to third-party servers.

I'm happy to provide any code or the project itself, for inclusion into lds.org so it isn't a third-party any longer. You can manually add individuals as well. Have there been any updates to this policy since 2007 or requirements to comply with properly storing such data? It is a secure server and access is restricted.

topherreynoso wrote:Have there been any updates to this policy since 2007 or requirements to comply with properly storing such data? It is a secure server and access is restricted.

No, there hasn't been. It's not a technical issue. It's one thing to set up a site and use it for your own unit. In that case, it's not really a 3rd party server since you control it. The underlying problem was collecting information for people outside of one's ward/stake.

As far as advancing the idea, I'm not sure what the best way would be. You could ask your stake president to talk about it with the Area Rep.

I already did and a seventy came and sat in on our ward council and enjoyed the ward area book. That's what made me think that others might find it useful and to make it available for anyone else to utilize.

A version for just one ward could be posted up on GitHub where anyone could fork it and create their own app hosted by a number of services (e.g. heroku), but that doesn't really solve the problem because you would still be utilizing a server owned by someone else. That would mean only individuals who own their own servers could use it for their own wards.

That link you provided also states that "If you have a web site that asks individuals to input data on their own, we currently do not have a policy about that." That makes it sound like it's not really a technical or a collecting information issue, it sounds like it's more an issue of the immediate source of the information. So perhaps the answer is to allow users to upload data but not directly from a csv from a church link.

topherreynoso wrote:That link you provided also states that "If you have a web site that asks individuals to input data on their own, we currently do not have a policy about that."

Note that it's saying it's ok for a member to input information about themselves. An example of that might be to register to attend a conference. Each individual goes to the site to register to attend.

Members are free to divulge their information to anyone they want to. But for the church to hand over that information to someone else without the member's consent seems like a significant liability issue.

I understand what you're saying but I didn't read it like that and the context of the conversation doesn't really fit with what you're saying. The web site referred to was a way for leaders to map all members with a csv. It wouldn't make sense for individuals to enter their own addresses to map their own homes. I would really like to see the document referred to in the link. Don't get me wrong, I appreciate your feedback on this, but there has to be something that has a little more weight than a comment in a tech forum by a tech community manager from six and a half years ago.

"I am working with the top managers at the Church on developing a more comprehensive guidance document that I will share with you once it is complete. This document will help you know what you can or cannot do and what steps you must take when working with Church data."

A couple of things I take from that:
1. It's not that you can't work with Church data, there are just some steps that need to be taken when using it, which is good since there definitely can be a lot of sensitive data out there.

2. If this document is still not available after being considered back in 2007, doesn't that imply that the minutia of appropriate usage isn't a top priority right now? Be smart, don't use data inappropriately, store it securely (be it on your phone, computer, or elsewhere), govern yourselves (that was the hope when they let you so easily export that data in the first place).

I think if you review the usage of it that I am proposing, it doesn't contradict any of that. I could be wrong, and am happy to address any vulnerabilities or do as instructed, I just had a tool we found useful that I thought I'd make available to others.

I believe the underlying principle is disclosing information outside your unit. What you do with the information you have access to is one thing. It's sending off to someone else that you really don't know and can't be sure that their intentions are fully on the up-and-up.

I'm not saying what you are doing for your ward is wrong - it's when other units start uploading to your system that's a problem. They shouldn't be doing that.

This info is dated. Here's a link to the church's official current policy.

https://www.lds.org/pages/internet-usage-helps

Under "Personal Internet Use in Church Callings" it states:

Use personal information found in stake and ward directories or other Church records only for Church purposes. This information should be shared carefully and only with those who need to access it to fulfill Church callings and assignments.

Store or display others’ personal information on your website, blog, social network, or other publicly visible software application only after notifying each person and obtaining his or her express permission.

As you can see, since this is not a setting that would be "publicly visible" there's no need to notify each person for express permission and you can control access so only "those who need to access it to fulfill Church callings and assignments" can reach this info.

Cheers!

I disagree. And I must say that I'd be very upset if my church leaders shared my private information and it found it's way somewhere where it shouldn't.

Note that depending on the local laws, a data breach of Personally Identifiably Information (PII) might have to be made public. That's not going to go over well.

topherreynoso wrote:As you can see, since this is not a setting that would be "publicly visible" there's no need to notify each person for express permission and you can control access so only "those who need to access it to fulfill Church callings and assignments" can reach this info.

I believe something helpful, at least for my consideration, might be a valid security certificate for the site you mentioned in the original post.

I have also found that all settings are publicly visible to those who are interested in seeing them. Personally, I would default on the side of caution. Even the Church requires opt-in in most countries of the world.

topherreynoso wrote:This info is dated. Here's a link to the church's official current policy.

https://www.lds.org/pages/internet-usage-helps

Under "Personal Internet Use in Church Callings" it states:

Use personal information found in stake and ward directories or other Church records only for Church purposes. This information should be shared carefully and only with those who need to access it to fulfill Church callings and assignments.

Store or display others’ personal information on your website, blog, social network, or other publicly visible software application only after notifying each person and obtaining his or her express permission.

As you can see, since this is not a setting that would be "publicly visible" there's no need to notify each person for express permission and you can control access so only "those who need to access it to fulfill Church callings and assignments" can reach this info.

Cheers!

Note that although the statement you quoted may apply to use of your site by your ward members, anyone else who uses the site is exposing their ward's information to you and as such violates the rule against sharing that information with "only with those who need to access it to fulfill Church callings and assignments." If you look back at the post originally mentioned, that was the primary concern:

The Church does not want other non-Church operated web sites to be aggregating data from various units around the world.

I don't see any indication in the current policies that this is not still the case.

I've contacted some others here at the Church about this. The closest thing I can point to on policy is taken from the terms of use:

http://www.lds.org/legal/terms

Which states:

You may not post material from this site on another website or on a computer network without our permission. You may not transmit or distribute material from this site to other sites.

Topher - you will likely get contacted by someone else from the church. Please keep in mind that they are trying to protect the privacy of members as best they know how. I understand that you are trying to fulfill your calling as best you know how. I appreciate the efforts everyone is making to further the work.

Thanks for the responses. lajackson, your concern on the ssl cert is valid and will be resolved later today. I was trying to gauge what kind of interest the project might have before I decided to donate any more money to this cause. Luckily there are some pretty good discounts out there on ssl certs. I don't agree however that all settings are publicly visible, and neither do the courts. While the "everything is hackable" argument is technically true, hackable does not equal publicly visible. If it did, and if the church intended you to not share this info at all, it wouldn't have used the qualifier "or other publicly visible software application" and would have instead just said "or any other software application."

eblood66, I see your point but with encrypted databases this isn't really so much a concern. I guess I could add a layer of a "ward-wide" password that the admin chooses, that is never stored on the server but admins can distribute to their users which would be required in order to decrypt the data stored each time you access it. That wouldn't be a bad idea. I also disagree with your use of that forum post again. I mean, if you look just a couple of years before that you see the church telling every leader to shut down even the use of an email group. http://bit.ly/1coL1pB

Obviously, different counsel for different times. We live in an age where the new church policy makes it very clear that other websites and software are fine, an age when the twelve apostles have official facebook and google+ accounts, when missionaries can use social media. The more ways to get people to connect in good, safe ways the better. That's the message I take from the recent counsel and guidelines. I appreciate your concerns, but I think this is well within the requirements of the policy.

I am always open to suggestions, specific security concerns, features (current and new) or bugs.

TimRiker thanks for the reply, I appreciate the discussion and do not mind at all getting contacted by someone.

topherreynoso wrote:I mean, if you look just a couple of years before that you see the church telling every leader to shut down even the use of an email group. http://bit.ly/1coL1pB

In many ways, it's still active. See Handbook 2: 21.1.22. The Handbook supersedes a mere webpage on lds.org.

As for the "Members’ Use of the Internet in Church Callings" it does contain the prohibition on "Photographs of other individuals or personal information about them should not be displayed without their consent." There's nothing that makes an exception for "private" or "leader only" web pages.

Sorry, I'm not trying to cause problems but I just don't agree. The website is the most up to date source of that information. Updates are made through means like these or letters from authorities before handbooks are updated. That handbook talks about ward and stake websites, which don't even exist anymore. The new posted guidelines omit the section about stake and ward websites because they are more updated. The fact that the updated guidelines make a distinction for "leader only" access and "publicly visible" software should be a solid indication that they are allowing more access, not the same or less.

topherreynoso wrote:The website is the most up to date source of that information.

The on-line handbook is more authoritative and it is updated as policy changes. If you want an example, look at the age limit for Single Adult wards. That's a recent change in the past few months.

topherreynoso wrote:eblood66, I see your point but with encrypted databases this isn't really so much a concern. I guess I could add a layer of a "ward-wide" password that the admin chooses, that is never stored on the server but admins can distribute to their users which would be required in order to decrypt the data stored each time you access it. That wouldn't be a bad idea.

The problem is that without the ability to access your server at the system level, others have no way to verify that your server doesn't have a back door that let's you access the information anyway (and most people aren't capable of such an analysis anyway). So they have to trust you. And I'm not saying you are untrustworthy. I sincerely expect that you are. But I don't know for certain and so I would not recommend use of your site for my ward even though it could be very useful.

topherreynoso wrote:I also disagree with your use of that forum post again. I mean, if you look just a couple of years before that you see the church telling every leader to shut down even the use of an email group. http://bit.ly/1coL1pB

My point was not whether the policy was still in force or not. My point was the motivation given for the policy. In nothing since then have I seen any sign that the church is more comfortable about having membership information for multiple wards on a third-party server. Yes, encouragement to use the internet to connect people has expanded but access to membership information has actually gone the other way. Back when that post was made many leaders were using the Ward Tools smartphone software (which used the MLS export) to have handy access to membership information. Since then the church acquired that software and shut it down. They replaced it with the official LDS Tools application which very tightly controls which leaders have access to which information. Since then they have also removed the MRN from the MLS export. The new lds.org Directory that replaced the old stake and ward websites shows less information on members of other wards in the same stake (i.e. children are not visible). Concern with protecting member information seems to be even greater than it was then.

Don't get me wrong. I applaud your efforts to help your ward and your desired to make this available to others is admirable. But personally I think the privacy issues are too touchy for this kind of app to be used by units generally unless it's an official part of lds.org.

eblood66, that's fair and I'd be happy to post the entire project on github and let anyone see the way that it works. I'd actually appreciate that, I would rather have it open to expose and address possible weaknesses and if you're interested, I would love the help.

I also see the cramping down on what is accessible as a sign that what's accessible is less risky, which means it's probably heading in the direction of being capable of integration into other software, coupled with the new policy saying it's okay to integrate, as long as the right precautions are being taken, that sounds like we're encouraging innovation and utilization of this data, specifically ward and stake directory info. This app only imports member info from the csv that the lds.org website intends for exporting. If they changed the data exported in that file to be more restricted, that is fantastic, less data for other software applications to deal with.

russelhltn, I completely agree that once those updates are made, the on-line handbook is the authority. Clearly though, tech policy changes have been made that have not propagated to the handbook yet (e.g. stake and ward websites, etc) and traditionally, that's not unusual. I've seen policies change that took quite some time to propagate to handbooks (even as a missionary!).

I think I'll just have to await that contact from someone else from the church. This started by quoting a comment on a tech forum as authority and told me there were no updates to this topic since 2007 and now, after learning that there is an updated policy, I'm told that the policy on the website is not authoritative. At the very least, that's confusing. I really do appreciate the time you've each given to this topic (and all of the time you sacrifice to this community, for that matter). Hopefully we will be able to bring some clarity for others going forward with current policies.

Just to be clear, I would only EVER do something like this if it were free and if I were confident in the security of members' data. Thank you, all!

Perhaps this might help: The Handbook is carefully gone over and correlated at the highest levels of the church. What you see on lds.org is at best correlated at the department head level. So the web page can add restrictions, but only something from the Quorum of the Twelve or Presiding Bishopric can override/change the handbook.

As for the mention of "stake and ward website", the migration to separate tools probably wasn't a big enough change to bother with the updating and correlating process as they didn't think it materially changed anyone's interpretation of it.

Hey guys,

I have not heard anything from anyone yet but I did want to update you on the status of the site. Work has been pretty busy but my goal is to accomplish the following in the next couple of days:

1. Fix the ssl cert.
2. Add the layer of "ward-wide" passwords that never touch the server and are used to encrypt all member data.
3. Make the code an open project on github so you can see exactly what the server does with information and can verify its security or notify me of possible vulnerabilities.

That should ensure that the site is both secure and that any church data that ever touches the server is always encrypted in a way that not even the server admin has access to it.

topherreynoso wrote:We found that it is much easier to share all of this information we gather about members and investigators in what we call our "Ward Area Book." Any visits or attempts to contact families are recorded in the area book by any member of the ward council. This way you can look up a family or investigator and see a running story of interactions with the ward. Additionally, it is a way to return and report without having to spend all of the ward council meeting time reviewing reports.

It seems to me that this is what HT and VT is suppose to be doing.

Ideally, yes the HT and VT take care of the needs of a family and this doesn't exclude that. If a ward council wants a report on a particular family, we would prefer to utilize the HT and VT and then it would just be the responsibility of the ward council member to report the result of that assignment to the rest of the ward council through the ward area book. However, HT and VT sometimes can't meet all of a family's needs, sometimes the bishop or the ward council are needed, sometimes people go through times that require more than a HT or VT visit. This is quite common work for ward councils to be involved in as families'/individuals' needs and well-being are meant to be the focus of the ward council.

Our ward council tracks newly baptized members for at least 12 months by assigning ward council organizations to visit monthly, each group visiting weekly. A couple with young lady and young boy could be assigned to be contacted by the EQ, RS, YW, Pri. A single older sister could be visited by RS, VT, HT, HP. A single dad with young children could be visited by EQ, YW, Pri, HT.
It can take up a lot of time in WC meetings so it is up to WC members to convey visit info to myself (Ward Clerk) and the bishop. In WC we then discuss the issues involved with these visits. These visits do not take the place of HT and VT.

Alright so here are the big updates on where http://www.ldsareabook.org is at:

1. SSL cert is resolved and valid
2. The code for this site is now 100% public. You can see all of it on Github at https://github.com/topherreynoso/LDS-Area-Book. That means that if you decide you would rather fork the project and run a whole website of your own with what I've built, have at it. I'm happy to answer questions about this process, just contact me.
3. I have removed all references to MLS or the directory on lds.org.
4. I have added the ward wide password which is chosen by the administrator of each area book. This password is used to encrypt all member data and is never stored anywhere on the server. That means that only other ward council members with whom you share the ward password will have access to any of the decrypted data. Not even a server admin, like myself, would be able to decrypt this data without each individual area book password. That also means though, that should you lose your area book password, there is no way to recover it and all data is lost.

I am still interested in hearing any thoughts on features, requests for other features, questions about security, bugs, or the like. Thanks, guys!

Topher,

I have come across your github, how does it get set up. I tried to figure it out, but I'm having no luck with getting it running. If you could provide some guidance, this would be extremely helpful in our ward.

Chris Perra
Assistant WML
Sioux Falls 1st Ward, South Dakota

chrisperra wrote:Topher,
I have come across your github, how does it get set up. I tried to figure it out, but I'm having no luck with getting it running. If you could provide some guidance, this would be extremely helpful in our ward.
Chris Perra

Same here, need help.

I just got off the phone with Brent Beachem over at the Church's ICS Risk and Security Department. He and his team were very kind and contacted me as a result of this forum discussion. They have indicated that the site is not in violation of their policy. The only issue they had with it previously was it's use of LDS account credentials for membership and leadership verification. Since all of that was removed previously and the site is open for any member to use and there is no connection between users and their LDS account credentials, http://www.ldsareabook.org is fine for use. Just to be clear, the Church does not in any way endorse the site, it just isn't violating the policy. I also can't say that any other site is approved, we did not really discuss that, but at the least they made it clear that this particular site is not in violation of any policy.

I will continue to make this code public, however, and you are free to roll your own website, but feel free to use the service for free at http://www.ldsareabook.org

Chris and showseason,

I would be happy to help you get your own site up and running with the code. Could you give me an idea of what your experience is, have you set up a ruby on rails application before? Are you familiar with Heroku or another hosting service or do you have your own server? Feel free to contact me directly and I can point you in the right direction if you have never done any of that before and I am also happy to help you figure out specific issues if you are familiar with running a rails app but are running into some problem.

Did they say anything about uploading MLS data? I know that was another concern.

They did not have any other issues with this site. Like I said, I can't speak for any other site or its use of data. But they were familiar with this forum discussion and did take a look at this site and created an account while we were on the phone and we discussed its uses and features. The only thing they gave a resounding "no" on was the use of LDS account credentials. Since that is not an issue with this site, it is ok for use.

Thanks for the help, Russell.

I do find it interesting that church representatives expressed no problems with the site. That may be in part because the users have to key in all the names, addresses, etc. themselves, manually delete or archive members' unofficial records when they move out, and manually maintain any detail changes such as address edits. I would not be too keen on doing that with a large ward that has a lot of turnover. (That problem seems inherent in any system that has no reliable logical links from the official database of record.) If there were more import-export functionality, with unique but non-confidential keys that the clerk could link to MLS data, that problem might at least be mitigated in some external tool for clerks alone to use. At least that could identify records to add, delete or edit. Still a lot of administrative work to maintain just the basic directory data that MLS has, before any new content such as contact notes is ever added.

One other observation is that the logic and structure of the site are hard-wired according a certain methodology and flow, which might not match different processes that other ward councils invent for themselves. For example, you have built in one subset category called "Watch List," but other councils might prefer more categories of their own devising. As another example, wards might want to track which quorums have primary HT responsibility for each family, and their move-in dates, but there is no place to record these variables or slice and dice the roster this way.

Because of such diverse local "business rules," different units might prefer the flexibility of generalized tools such as shared spreadsheets. (Which, of course, present their own set of problems precisely because they do lack the discipline of a structured user interface and many-to-one relationships in a database.)

I mean all this constructively.

I can't tell you how nice it is to have feedback on the actual app rather than a discussion on church policy (albeit an understandably important discussion).

The app does allow you to import a csv of user info and import another csv with updated info at any time. This will automatically let you know when families should be moved to the archive and when new families should be added. It also identifies families with info that is different than the csv, letting you see and decide what to update and what to leave out. I like this format because it allows the ward council, who often ends up with updated contact info, to input this info in the area book (since most of them don't have MLS access) and it let's me, the clerk, see that our ward book has info that I need to submit to MLS. Minimal maintenance effort. It's a matter of getting the csv and checking a few boxes at import time.

I do agree that some more flexibility would be good and I am open to suggestions! Thanks for the feedback.

topherreynoso wrote: The app does allow you to import a csv of user info and import another csv with updated info at any time. This will automatically let you know when families should be moved to the archive and when new families should be added. It also identifies families with info that is different than the csv, letting you see and decide what to update and what to leave out. I like this format because it allows the ward council, who often ends up with updated contact info, to input this info in the area book (since most of them don't have MLS access) and it let's me, the clerk, see that our ward book has info that I need to submit to MLS. Minimal maintenance effort. It's a matter of getting the csv and checking a few boxes at import time.

I like the idea of a csv import. (I had misunderstood from the earlier discussion, thinking all such functionality had been removed to satisfy the forum policy police.) Is this csv format designed to your own spec, or is it an export format from either MLS or lds.org? It is not very feasible to mix up these two sources of directory content, because their name content is not compatible. In my ward, for example, almost 15 percent of the household names disagree between the MLS and lds.org directories for various reasons -- mostly because non-member spouse names are included in the latter but not the former.

Allowing council members to update contact info raises a huge red flag for me as a clerk. There has to be a single authoritative source of such data, and it is dangerous to encourage the council to edit this ad hoc database and think the master database has been updated when it has not. MLS and lds.org, which are cross-synced, comprise that authoritative source. If other council members have updated contact info, they should communicate it to the clerks to update the authoritative source. (Your finding-note transaction items are a good place to do this.) I suggest making all the name-address-contact fields themselves read-only except for clerks.

You can use a csv from lds.org but you are also free to make changes or create your own, the lds.org export is just the fastest way to get to a list of household names. I think you misunderstand the import and ability for ward council members to update info. The ward area book is not the authoritative source of member info, that would be MLS and lds.org (since lds.org derives its info from MLS). But allowing ward council members to update family info in the area book isn't at all an issue because any changes are easily set back by doing an update from a csv if the administrator so chooses. It's quick and pretty simple but, alternatively, during that update if I notice that info is different I'll look at the date of update and know whether the ward area book has more recent data or if the new csv import has the more recent data and I can decide whether or not an update to MLS is appropriate for me to make.

One day a month our entire ward council gets together, meets for just five minutes and then we all go out to see individuals and families that our organizations are focusing on or new members, or less active members that we have little information on. We live in a beach city so we get a good amount of traffic, transients, young adults, people we have little information on etc. on almost a monthly basis. This allows the ward council, in our monthly efforts, to gather information in these situations without me having to spend much time chasing behind each ward council member, they just report their visits here, update info they receive here (after all the ward council group is a generally responsible and reliable group) and then the bishopric can follow their progress, review knowledge about families and individuals easily without having to do it all in WC meetings.

One other feature that many ward councils would want is a free-form notes field attached to the header record for each household. As I understand your structure, the only free-form text fields are in the time-stamped finding-transaction records.

I have seen lots of ad hoc spreadsheets concocted by various councils, PECs, quorum presidencies, etc. over the years to record stuff about members and/or households. All have had such notes content because no one can keep all that straight in their heads. It is a good bet that headquarters will never add such features to official systems. But local leaders usually want them in their own files somehow, despite the risk of misuse.

BTW, I am glad to hear that the church representatives did not express objection to importing basic csv directory files exported from lds.org. (Structurally, I would prefer the MLS export format, or even both to accommodate differences.) But the export-import precedent is important to know.

Excellent point on the family notations and one that a few other members of my ward council had requested. I will set about implementing it in the next few days.

RE: importing CSVs (sorry to turn this back into that discussion, because it's not an interesting discussion to me and I hope this is the last time I address it, I'm far more interested in ways to actually help ward councils)

I don't know what the exact policy is other than what is posted on lds.org which has been discussed in detail on this forum. I don't know how these policies will be handled in other situations. All I can tell you is what I built and what I've heard from the church regarding what I built. I built a tool from which I derive no profit and which is publicly available on a code level with an import feature in which all imported data is always encrypted on the server in a way that not even a server admin has access to decrypted data, and which the person who imports it has complete control over who can view the data. How much of that is required to avoid violating a policy? I have no clue. All I know is that I have been contacted by people who are actually authorized to speak on behalf of the Church and no violation of the policy has been indicated to me.

It is encouraging to know that Google and Dropbox servers are not the only servers deemed worthy of holding data like this, especially given the motivations and security issues of companies like those (not to imply that they're evil or anything, I'm just saying it would be strange to "ok" a company that literally crawls your documents to identify better ads for you but restrict an app like this one).

Quick update: the app now supports family notes as previously mentioned by RossEvans. I also cleaned up some scrollbar issues that were quirky in IE. I don't have regular access to an IE browser so if anyone sees anything else that seems off, feel free to mention it to me here or raise an issue on the Github site and I'll get it resolved.

I am very happy to have found this! A tool that is pretty well developed already and has much of the functionality needed. I am a Ward Mission Leader and therefore a ward council member and I would love to leverage this tool to help manage ward mission efforts in addition to general ward council efforts. I have many ideas and there has been a form started on linked in for the same. I will direct them here and I imagine you will have plenty of feedback.

On a side note, I do not see the ability to import csv data. Is this because I am not set up as a ward clerk? How can I gain this ability as I will be the one managing the site for now?

I am going to give it a good look over and offer some feedback. Thank you for your efforts!

Unkown4now (how mysterious),

I'm glad you have found it and hope it helps your ward council like it has mine. After you create a new area book, you can press the green button at the bottom of the Ward List in order to import a CSV. Obviously, the first time you import there will be a lot of families to add but after your initial import, you can run another import with a CSV of more recent info at any time. That will let you see a list of families that are new, families that should be archived, and families that have updated contact or other info since the last import. Regularly importing is advisable. I hope that helps!

I see.... the green refresh button. That is what I needed. (I guess I could have clicked it to see what it does...ha)

Feedback already:
On my first import, I got an error, I re-imported and got same error. Click on my ward list and there were 20 or so names imported duplicate times. Not a big deal except I can not easily identify how to delete someone. My only option seems to be to delete the ward.

Also, on import, I only saw the first 3 names of the CSV and was not able to scroll up and down. Only side to side. As a result, I just selected check all and imported.

By the way, I am using firefox browser. Going to see if app functions differently in IE.

Recommendations:
Add an "Edit" capability on the ward list to allow you to delete an entry that may be a duplicate. This should be a check box next to each name with a button you click to delete selected. (If this is user error, or not commonly used post import then it would be low priority)

Definitely works better in IE although each household row is 4 inches. Possibly an autosize based on the largest household? If so, having the autosize by row would be better.

Also, got the same error on import:

"We're sorry, but something went wrong.
If you are the application owner check the logs for more information"

At least I have enough info to test the app...

Strange, was working last week without a problem. I am able to generate the error and will address it tonight. Would you mind telling me the source of your csv and whether or not you made any specific alterations to headers or anything like that?

Also you can archive a family by clicking on their name in the ward list (or anywhere else for that matter) and use the yellow "Archive Family" button. You will need to go to the archive and select the family to then have the option to permanently delete though.

Okay this issue is resolved and working properly, please let me know if you are still experiencing issues. Just a couple of thoughts though:

1. You can use the "Help" link from within the app, those resources are pretty exhaustive on the current features, so if you ever get stumped feel free to check the help files.
2. I think this is a great forum to discuss features and suggestions but it's probably best to take specific issues or bugs to the github site and report them in issues. Github does a much better job at tracking such things and notifying those interested of any updates.

Thanks for the feedback and help, I look forward to improving the app and finding out what other wards find useful and what needs improvement.

Topher,

Thank you for creating this innovative tool for ward council members to collaborate on missionary work! This is the kind of forward thinking that we as members of the Church need to be progressing to help further the work!

Thanks and I'm grateful that you are working on it still. I imagine that since you have released this for collaboration on GitHub the development could continue further still with more contributors and potentially become part of an official app which would be awesome.

I can visualize a digital area book that ward council members *and* full-time missionaries can access to keep everyone on the same page!

Regards!

It may be a good idea to find a way to obscure the admin email address when showing the list of wards that you can request access to.

I set up a new ward, poked around, then deleted it. For now. I might come back to this. However, after I deleted the ward and signed out, I get an error when I sign in again: "The page you were looking for doesn't exist."

I agree with @williamjackson, having privacy even if obscured is a good idea. I don't think having the ward admins name and email is needed. There could be a button that says 'contact administrator' or something.

Thanks!

That's a good suggestion, I did it really to make it easier to confirm whether or not the ward area book you were requesting access to was the correct one. I guess I could create a "Contact Admin" button and set up a form to send the administrator an email from ldsareabook.org with the user's question and contact info for a reply. I'll get into it tonight and check out the error after deleting a ward. Thanks, everyone!

Topher, One other idea would be to allow a description field for the Ward name, where maybe in small text under the Ward name it would say the description. Or alternatively you could have a field for Stake. This could replace the description idea and show as small light text under the ward name. This would also help prevent issues where there might be two wards with similar names, such as Two Rivers Ward etc. Thanks!

Ok, sorry for the delay on this one, it's been a long week. I looked into the issue with deleting wards and found the culprit, that bug has been fixed, thanks for bringing it to my attention. I have also removed admin email addresses from the area book list and instead there is a "Contact Admin" button that takes the user to a form to send an email to the admin. The admin is provided with the user's name and email address along with their message and can decide how to respond on their own. I also made it so that an email notification is sent to all admins of an area book any time a user requests access to the area book and an email is sent to a user anytime an admin changes their permission status (accepting or denying a request for access). Thanks for the suggestions and help in making it better!

Great new updates!

There were some full-time missionaries that checked this out and thought something like this would be awesome. They won't use it now without approval, however, this is headed in a good direction.

I wonder if there is a possibility of this being merged with an official effort from the church potentially?

Glad you liked the updates, I look forward to getting more feedback. Our missionaries already utilize the app but they got permission from their President so maybe just ask them to do the same. I would definitely be open to having collaborators on the github project who are rails skilled and would like to contribute. Contact me directly, if anyone is interested in that.

I would happily merge this into an official church effort in the future but, thus far, I have not heard anything along those lines from anyone at the church. Maybe if enough Ward Councils utilize it, help me fine-tune it, and like it, then there would be more of an interest.

That is awesome. Its great that you are developing it in an open manner. That can only benefit the overall app. If I had rails skills, I'd contribute!

Anyways, I think that is the next step, they are going to share it with the President, as it would be very beneficial for us to all collaborate.

What if they have security concerns about the data in a 3rd party non-official database, have any advice on how to calm minds?

Thanks!

Security of data has been the number one concern, both in building it and as a topic in this forum. There are several layers of security built in to make sure that data is secure:

First, all interactions with the site are done over SSL.
Second, each area book administrator has to approve any user before they have access to the area book.
Third, each area book has a password that the administrator sets and controls and only shares with individuals who they want to grant access to the area book. This password is used to encrypt all imported member info and the password is never stored on the server so even someone with server access has nothing but encrypted gibberish without each individual area book's password.

Finally, the site has been seen by an area authority and I have been in contact with the Church's Risk team and no violation of any Church policy has been indicated to me. Not an endorsement by the Church, but just in case they are wondering, it's not like I'm trying to fly under any radar or anything. The Church knows it's there and hasn't expressed any concern.

I am not sure how this does not violate Church policy. In the Presiding Bishopric's training on information security, it clearly states to not upload confidential information to 3rd party servers. To me, any data that is exported out of MLS or LDS.org should be considered confidential & sensitive. It is interesting that the Church's Risk department did not mention this.

dfchamplain,

Welcome to the forum. This topic has been covered ad nauseum. Please read through this forum for a thorough discussion and links to the current posted policy regarding ward and stake directory info as well as a discussion of feedback from the Risk department regarding this app (I can't speak for other apps or how it will be handled in other scenarios, only what I have heard from the Church regarding what I have built).

Best,

I went back through the previous posts in this forum and could not find any links to the Presiding Bishopric's training nor any previous mention of it. I also saw the feedback from the Risk department, but again, it does not appear that anyone has made mention of the training which I posted about. If I have missed this and it does appear, I do apologize. Please point me to the relevant post so I can further review.

dfchamplain wrote:I went back through the previous posts in this forum and could not find any links to the Presiding Bishopric's training nor any previous mention of it. I also saw the feedback from the Risk department, but again, it does not appear that anyone has made mention of the training which I posted about. If I have missed this and it does appear, I do apologize. Please point me to the relevant post so I can further review.

I can't find anything in that training that specifically mentions uploading data to 3rd party servers. There are general guidelines, at least some of which should be considered carefully before using any 3rd party service like this, but I don't see a clear cut prohibition.

dfchamplain wrote:I went back through the previous posts in this forum and could not find any links to the Presiding Bishopric's training nor any previous mention of it. I also saw the feedback from the Risk department, but again, it does not appear that anyone has made mention of the training which I posted about. If I have missed this and it does appear, I do apologize. Please point me to the relevant post so I can further review.

Sorry for the confusion, I did not mean that this particular training was discussed previously, I meant that the current church policy regarding using ward and stake directory information was discussed previously along with feedback from the Risk department regarding this app as well as the security measures used to ensure the safety of data discussed.

Also, I know a couple of people have reported a few importing issues for families with a lot of data (i.e. the length of certain information fields) and I will be updating the site soon to address such issues and will let you know when they are fixed.