[Ldsoss] MLS blocking (was: Wireless Networks in Church Buildings)

[Dave WORMELL]

If you adjust your schedule to a more specific time to Send/Rec you may find 
a way to work around this. I perform a Send and Recieve first thing on 
Sunday hours before Church begins. I also perform another Send and Receive 
before tithing begins. This way the computer is not tied up when someone is 
in a crunch for information and major financial information is not getting 
mixed up. You can also spend your time doing membership changes during a 
week day (rather than Sunday) and when no events are occuring at the 
Building (eg. Scouts)



--dave wormell





>From: "Idaho Joe" <idahojoe at gmail.com>
>Reply-To: LDS Open Source Software <ldsoss at lists.ldsoss.org>
>To: "LDS Open Source Software" <ldsoss at lists.ldsoss.org>
>Subject: [Ldsoss] MLS blocking (was: Wireless Networks in Church Buildings)
>Date: Wed, 22 Nov 2006 16:07:43 -0700
>
>On 11/22/06, Ben Galbraith <junk at galbraiths.org> wrote:
>>
>>On 11/22/06, Idaho Joe <idahojoe at gmail.com> wrote:
>> > By the way, it's been one of my pet peeves since I started using MLS,
>>but I
>> > was wondering if I was the only one that thought that locking MLS and
>> > preventing any further action during transmission was a poor design 
>>idea
>>on
>> > their part?
>>
>>Good feedback. In general, making user interfaces concurrent result in
>>significant additional complexity, which in turn requires a good deal
>>of effort to engineer properly. I'll pass your feedback along. How
>>much of your time does this behavior wind up wasting?
>
>
>I agree that it can add a lot of complexity to the problem, which is why I
>would propose that they still lock it for updates, but can be opened for
>read-only access (like printing roles, or a custom report that someone
>wanted or looking up a membership record, or printing out the year-to-date
>donations for a member, or whatever.)
>
>It almost never fails, just as soon as I click transmit, someone will walk
>through the door, and wants to lookup a membership record number or
>something.
>
>As for how much time it "wastes" that's relative to how much data the
>membership clerk, or HQ has modified and needs to be transmitted.  We're
>still using a modem, so it can take upwards of 15-30 minutes.  Generally
>however, it's only 5-10 minutes.  So I do get a chance to get to know a
>member of the ward or two now and again.  But personally, I'd rather do it
>under other circumstances.
>
>>Also, as finance clerk, I'm pretty good at making sure I transmit my
>>changes
>> > to SLC.  However, it often annoys me that instead of taking just a 
>>short
>> > time to transmit my finances, I get a lot of membership updates, and
>>have to
>> > print out all those reports.  Sometimes I really wish that if a finance
>>guy
>> > transmits, only the finances are dealt with.  Likewise for membership
>>I'm
>> > sure.  (Although I doubt he ever gets finance reports)
>>
>>Good feedback; I'll pass that along.
>
>
>I haven't given this a whole lot of thought, but I have given an initial
>consideration as to how I would solve this.  At first I though of simply
>transmiting/receiving only the things that an account has access to modify.
>(the check boxes in the permissions section of the account setup screen)
>But once in a while a finance clerk or membership clerk may have admin
>rights for whatever reason.  This would then mean that a finance clerk 
>would
>have update rights to membership data and so on.  So account permissions
>isn't necessarily a slam dunk.
>
>So far, the only solution I've even come close to arriving at is one based
>on callings.  MLS would have to be smart enough to know that the "jgrover"
>MLS account is attached to record number xxx-xxxxx-xxx which is currently
>called as "the finance clerk", and therefore would only submit and accept
>finance update transmissions.  EQ Pres would only have to transmit HT visit
>info, the Ward Clerk would send both finance and membership data, and so
>forth.
>
>>  My apologies for the tirade.  It's just something that has always
>>bothered
>> > me, and I can't explain why.
>>
>>It's a separate thread to explore this topic, but of course we're all
>>very bothered by software that forces us to go through extra work to
>>accomplish repetitive tasks -- especially those of us who by our
>>natures try and be as efficient as possible.
>>
>
>I realize this may not be the place, but I just though I would mention it
>because I suspect I'm not the only one noticing these things.
>
>--
>-- Joe


>_______________________________________________
>Ldsoss mailing list
>Ldsoss at lists.ldsoss.org
>http://lists.ldsoss.org/mailman/listinfo/ldsoss