Re: visiting teaching
boomerbubba
VisitingTeaching.csv file, apparently starting with MLS 3.3.0.
My own analysis of the anomaly in my ward's recent export data
confirms that the business rules that formerly were applied to phone
numbers and email addresses in this file (for Sister taught,
Supervisor, Visiting Teacher 1 and Visiting Teacher 2) are not being
followed reliably. That can affect us badly because these elements
are significant when we match members in HT/VT to their records in
Membership.
To recap, those business rules for these phone and email columns in
VisitingTeaching.csv were believed to be:
If the sister has an Individual Phone in Membership.csv, then use that
Else use the Househoold Phone if she has one
Else null string.
If the sister has an Individual E-mail in Membership.csv, then use
that
Else use the Househoold E-mail if she has one
Else null string.
The maddening thing is that these rules are still being followed for
almost every sister in my ward. Bur for a handful, either the phone,
email address or both in some records fpr Sister Taught, Visting
Teacher 1 or Visiting Teacher 2 are wrong. (I suspect that Supervisor
might also be affected in some cases someday, but there are so few
supervisors that we just didn't happen to trigger the bug in my ward.)
I can discern no pattern to why this bug occurs only for a handful of
records, so I don't think it was just a matter of an unannounced
design change in MLS. This is an unresolved bug. I will be reporting
it to MLS support. I recall that was a gross bug in early beta builds
of MLS 3.3.0 -- data in the wrong columns of Visiting Teaching.csv
altogether. I suspect that this subtle new bug was introduced when
they patched that one. (But I'm not optimistic. MLS support is still
in denial about the last bug I reported to them.)
--Ross
On Mar 1, 9:15 pm, boomerbubba <boomerbu...@gmail.com> wrote:
> The good news is that I now have found examples of this problem in my
> own ward. The bad news is that I have not yet found the root cause.
> At least I have data that I can explore without violating any
> confidentiality.
>
> My hypothesis is that during the MLS conversion to v 3.3.0 or 3.3.1,
> there was some subtle change in the rules the MLS developers used to
> compose the phone numbers and email addresses in the
> VisitingTeaching.csv file. (I don't find the same problem when I load
> with exports from MLS 3.2.4.) I will keep looking, but I am a bit
> pessimistic about a solution. If we change our logic to match some
> new -- and possibly buggy -- MLS logic, we risk being whipsawed by
> future problems if MLS developers discover their bug and fix it.
>
> On Feb 2, 10:04 pm, Randall Mudge <rmudges...@gmail.com> wrote:
>
>
>
> > Have problems with visiting teaching showing up, some show up others show no
> > visiting teaching assigned, have looked at file in excel and cannot see any
> > diferences between the ones that show up and the ones that do not.
>
> > Any help would be great.
>
> > Thanks
>
> > --
> > Randall L Mudge
> > PGA Head Golf Professional
> > Stockdale Country Club
> > 661-832-0587 Golf Shop
> > 661-832-0310 Club ext 116
> > 661-832-6590 Fax
> > 661-912-4033Cell- Hide quoted text -
>
> - Show quoted text -
Andy Wilbourn
boomerbubba
offered to send them more details, including my summary query results
showing the bad records, the export files themselves and an MLS backup
from the same day. But I wasn't going to use email for that stuff.
BTW, the other bug I reported yesterday was in HomeTeaching.csv.
Starting with 3.3.0, as far as I can tell, there are bogus records in
that file with only the Household column populated in the form "Name
Unknown, William John" where "William John" is the given name of a
recent move-out. These records internally are an artifact of the
need to keep recent move-outs as hidden records in MLS to facilitate
HT statistics for the quarter.
I don't think this one really hurts us. My transform script
effectively skips them, although really by accident. I have also
tested this file and its companion exports against the Ward Tools MLS
Converter for .pdb, and the converter ran without apparent error. I
can't verify how the data looks inside Ward Tools itself on iPhone or
Windows Mobile. And of course, I don't know about Andy's Blackberry
app.
Anyway, it was sort of amusing that MLS support responded off-point,
referencing a different MLS function entirely (the ""Households not
being Home Taught" report) and saying this is a feature.
--Ross
On Mar 3, 5:44 pm, Andy Wilbourn <awilbo...@gmail.com> wrote:
> Perhaps it is related to new assignments vs unchanged with the new update. I could see that being an issue possibly.
>
boomerbubba
well.
But I think at least I have found a pattern: Interaction between the
new lds,org website and MLS. I suspect that the members in question
edited their contact information in the online directory, which got
pushed down to MLS and was applied inconsistently.
See my post here:
https://tech.lds.org/forum/showthread.php?7174-Apparent-bugs-in-MLS-export-files-%28v-3.3.0-and-3.3.1%29&p=58787&viewfull=1#post58787
--Ross
On Mar 3, 9:34 pm, boomerbubba <boomerbu...@gmail.com> wrote:
> I have reported this visiting teaching bug via msrm...@ldsmail.net. I
Kevin Turpin
Our clerk's computer just received an update to MLS version 3.3.1. I don't have any way to test this scenario, but I wonder if one reason for the quick update (3.3.0 was released so recently) is to address this type of problem where a member can change data on the website that adversely effects MLS at the ward level.
- Kevin
boomerbubba
I don't think so. My unit already had 3.3.1 installed last week, and
my testing found the bug in our 3.3.1 data.
--Ross
On Mar 5, 9:59 pm, Kevin Turpin <kevin.tur...@gmail.com> wrote:
> Ross,
>
> Our clerk's computer just received an update to MLS version 3.3.1. I don't
> have any way to test this scenario, but I wonder if one reason for the quick
> update (3.3.0 was released so recently) is to address this type of problem
> where a member can change data on the website that adversely effects MLS at
> the ward level.
>
> - Kevin
>
> > The bad news is that this bug apparently infects HomeTeaching.csv as
> > well.
>
> > But I think at least I have found a pattern: Interaction between the
> > new lds,org website and MLS. I suspect that the members in question
> > edited their contact information in the online directory, which got
> > pushed down to MLS and was applied inconsistently.
>
> > See my post here:
>
boomerbubba
today and and viewing the records within the MLS user interface (in
the Household Contacts dialog) it now appears that it is the
Membership.csv export file that is wrong.
The MLS screen (like the website) shows the Household Email to be
blank, but Membership.csv shows it to be populated. The
HomeTeaching.csv and VisitingTeaching.csv files both show the Email to
be blank.
The major effect on Ward Tools (at least in the Android version) would
still be that some HT/VT assignments might be missing, because the
conversion scripts rely on the contact data in HomeTeaching.csv,
VisitingTeaching.csv and Membership.csv to be consistent. Another
effect would be some data in the Household E-email when there should
be none.
--Ross
boomerbubba
I am a household of one. I first cleared both my Household E-mail and
my Individual E-mail via the website. After allowing time and doing a
batch send/receive, the edits appeared correctly in MLS: Both fields
were blank in the user interface. Both fields were also blank in the
Membership.csv export. So far so good.
Then online I added a value to only my Individual E-Mail. After enough
time and another send/receive, that value was correctly added to the
Individual E-mail field in the user interface, and my Household E-mail
correctly remained blank. But in Membership.csv, the new value
populated both the Individual E-Mail column and (incorrectly) the
Household E-Mail column.
This may not be the only case that triggers such an error, and I have
not experimented with the phone fields. (Maybe there is even a case
that can replicate the behavior directly within MLS without an update
from the web service.) But there is a bug, and a scenario that can
replicate it.
Meanwhile, I did receive a reply from my bug report indicating that at
least it has been forwarded to "the MLS programmers." So hopefully it
will get found and fixed.
boomerbubba
"This is more or less a bug that occurred in a previous version and
appears to be recurring. We are working on addressing it, so it is not
in the release notes as it is not intended."
That is good news. But as I sort out the emails, I see this one
apparently applies to the "Name Unklnown" bug in Hometeaching.csv.
The Membership.csv bug is a separate case.
boomerbubba
* Affects MLS Custom Reports as well as Membership.csv exports.
* Affects the the Household Phone field (called Household Phone
Number in Custom Reports) as well as the Household E-mail field.
* Occurs whether the underlying data is updated within MLS or
online.
In both Membership.csv exports and Custom Reports, the fields labeled
Household Phone [Number] and Household E-mail no longer faithfully
contain the content of those fields as labeled within the Contacts
Screen of MLS or the online Profile editing page. Rather, there seems
to be a complex rule being followed in MLS:
If there is an underlying Household E-mail present in the real data,
that will be used in the export and reports. Otherwise, MLS will first
try to construct a surrogate Household E-mail from the Individual E-
mail of the Head of Household. Similar logic applies to the fields
labeled Household Phone. The exports will try to concoct a surrogate
Household Phone from the Individual Phone of the Head of Household.
Except for pro forma acknowlegement of my bug reports, I still have
heard nothing back from the MLS team about this issue.
--Ross
>
> read more »