Can anyone point me to a place that has the format and fields available in the files output from MLS?If the testdata is not ready available then at least the list of fields in each file as we dont have MLS installed.

There seem to be a vast amount of applications out there to assist the functionality of the MLS system and no doubt more will arrive.I am myself seriously thinking about creating an application to help in certain areas. I am well aware of the security issues with membership data and the grey areas and so on this issue I have emailed Tom with my suggestions for how I would deal with sensitive data. Its possible to be much more secure than most people would be with a CSV file on the laptop or typed out reports in their briefcase.

To give you a bit more information about my thoughts:

My main aim with the application would be to be MLS for the individual members and help them serve in their calling. Some of the functionality might simply be a link to lds.org or other useful site. Other functionality might have to be written separately. Another major focus would be to assist leaders (in their calling) when attending meetings.

We cannot all be graduated project managers in the church and used to keeping check of all tasks and so my aim would be to let the program keep check of actions taken at the various meetings and for these to be visible via the application to both the person assigning and the person assigned to.

It would therefore also help put together an agenda and put an end to 'meetingitis" and hopefully help prevent meeting actions being lost in space because of lack of "follow up".

I see great potential for this particularly in small units where calling an Exec Sec and having two counsellors is a luxury. Having presided over and attended countless Branch Presidency, PEC & Branch Counsel Meetings I see real potential here for all involved.

There are other areas where I see potential but more about that in v2 (releasing and calling people). For now I am just interested to see what kind of information is available for output in MLS to work out what would be stored locally encrypted and what could be transfered encrypted via the net as well as working out what functionality is not worthwhile doubling up on if MLS already supports it.

dkjorgi wrote:Can anyone point me to a place that has the format and fields available in the files output from MLS?If the testdata is not ready available then at least the list of fields in each file as we dont have MLS installed.

I'm a bit confused about how you propose to use "files ouput from MLS" at all if you don't have MLS installed.

boomerbubba wrote:I'm a bit confused about how you propose to use "files ouput from MLS" at all if you don't have MLS installed.

The purpose for creating the program is not just for us but for everyone elsewhere.Importing from MLS wouldnt be a requirement but it would help a lot to get started.If we had MLS installed here I could have got files from that and wouldnt have needed to ask for the format.

dkjorgi wrote:The purpose for creating the program is not just for us but for everyone elsewhere.Importing from MLS wouldnt be a requirement but it would help a lot to get started.If we had MLS installed here I could have got files from that and wouldnt have needed to ask for the format.

I hope that explains it better.

I guess I don't understand who you mean by "we." Are you a leader or clerk for a unit that does not use MLS?

In any case, I know of nothing in the MLS export files that relates to your idea about meetings and tracking action items from those meetings. If you want to build an application to do that, you might as well build it standalone, without reference to MLS. Since this is a generalized problem that obtains with anyone's meetings in any organization, there might well be generic software to do what you suggest.

From the [url=http://www.lds.org/Static%20Files/PDF/STS/Troubleshooting%20PDFs/00262_000_Mar05_notice[2].pdf]Policy and Guidelines for Computers Used by Clerks for Church Record Keeping[/url]

"The assistant stake clerk assigned to manage Church computers has the following responsibilities. He: [...]

12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software."

In all fairness, item #11 reads: "Ensures that ward clerks do not install Church record-keeping software on their home computers and that they do not reverse-engineer record-keeping software code."

We have since learned in this forum that it's acceptable to install the software, just not the membership data. I'm not completely sure what the concern about item 12 is or where the line would be between an electronic copy (such as what's printed by the Palm export) and what would be "record keeping software". I could speculate (I'm good at that ), but it would be just that - speculation.

RussellHltn wrote: I'm not completely sure what the concern about item 12 is or where the line would be between an electronic copy (such as what's printed by the Palm export) and what would be "record keeping software". I could speculate (I'm good at that ), but it would be just that - speculation.

If I have learned anything from exploring such issues on this forum, it is that published Church "policy" in such matters is sometimes ambiguous, out-of-date, or contradictory, and that we who hope for clarified policies will be waiting a long time indeed.

12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software."

I could speculate (I'm good at that ), but it would be just that - speculation.

Russell, I am not sure where you are going with this. If we are to interpret it the way you are leading up to (by mentioning it at all in the context of my original question) then one has to ask itself why the option to export such sensitive data is there in MLS in the first place.

#12 is very ambiguously described. It could even sound like it would prevent me from doing my day2day job On the other hand, why are priesthood leaders prevented from developing? Would my software be ok as I want it to be freeware?

If I had to guess then I would read #12 together with #11. I get the feeling that it means we ought not to profit for creating other software by tearing apart MLS and knowing what is going on in there. Maybe I am wrong.

All I know is I am keen to plug a gap where I see potential and at the same time also tighten up security of the data stored. Needless to say that any security on a desktop application is better than having the CSV export files from MLS sitting on a Palm or PC.

dkjorgi wrote:#12 is very ambiguously described. It could even sound like it would prevent me from doing my day2day job On the other hand, why are priesthood leaders prevented from developing? Would my software be ok as I want it to be freeware?

If I had to guess then I would read #12 together with #11. I get the feeling that it means we ought not to profit for creating other software by tearing apart MLS and knowing what is going on in there. Maybe I am wrong.

Although #12 doesn't specifically mention Church software, any reasonable interpretation of the context of the guidelines would acknowledge that the prohibition on the use of "tables, schemas, and the like" means you may not use the tables and schemas that underly Church software. Your day job that may use other tables and schemas (as does mine) is still just fine with the Church.

The prohibition on "third-party" software means it doesn't matter if it is free or not -- it is prohibited if it uses the underlying structure of MLS. I'm sure clerks and priesthood leaders are prohibited, as there is an assumption that they are the ones with access to MLS; the spirit of the guideline means that everyone else in the world is similarly prevented from freelance development based on the underlying tables and schemas.

But some wonderfully innovative and helpful tools have been created based on the established export files, and I see nothing in the guidelines that prevents such software development, as long as privacy and security of the data is properly maintained.

I'm not sure either. But it's written policy and seems to touch on what you are doing. It's a point that I thought should be tossed out for discussion. Isn't it better that this is worked out before you start coding rather then after?

As for what it means, is it a prohibition against anything that reads the MLS database directly? Is it to insure that MLS is THE record keeping software of the unit and that it not be replaced by something else? If that's the case, then I don't see a problem with what you are doing.

But if it's something against "third party record keeping software" then that's something to think about. It's one thing to use the export as a computerized printout - to be able to search and find the information needed. But if this application collects and stores additional information, then it might be viewed as something that might be prohibited.

As far as what kinds of notes are kept, based on another thread about record keeping, it's one thing to have the equivalent of a "area book" where missionaries pass a set of notes to their replacements. It's quite another to have a dossier on members that is passed around between ward leaders. You might want to carefully consider what information your application will collect and how it will be stored or distributed. Free-form notes could be abused, but a check box for "follow-up with Home Teachers" would be safe.

But, there's a bigger problem. According to this thread, CSV files will be done away with and replace with vCard. I wouldn't think about doing anything until that's settled.

RussellHltn wrote:12. Ensures that priesthood leaders and clerks do not use tables, schemas, and the like to create third-party or commercial recordkeeping software.....

I had read that document online, though I wasn't sure what it means exactly. Since I am not in that calling, I don't have to interpret its definition of the job description. Alan_Brown's reading of the language seems reasonable to me -- the "tables and schemas" are a reference to the underlying data structures of MLS itself.

It does seem that the language could not have been intended to refer to the export files, or those export files would not have been provided as they have been for years. Such a reading would thus be absurd. Yet quite obviously each .csv file is logically a table, and there is an implicit schema -- albeit a technically klunky schema -- that relates them.