Tech Forum

After further testing, it appears that this bug:

• 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 at lds.org. 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 as entered, 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.

RossEvans wrote: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 as entered, 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.

Sounds like a feature rather then a bug (although I can see where it might be a problem if one is unaware of the substitution - especially if your report is listing both.)

RussellHltn wrote:Sounds like a feature rather then a bug (although I can see where it might be a problem if one is unaware of the substitution - especially if your report is listing both.)

Only if you believe that wrong data is preferable to no data. If the user (member or clerk) leaves one of these fields empty, that user's choice should be respected. If this is a "feature" that bizarre design choice should be documented.

I can see how some report element might be designed with some such logic, so long as the data is labeled something different from the simple data of the same name and documented. For example, within Custom Reports there is a convenient element called Contact E-mail, IIRC, which has logic that it contains the person's Individual E-Mail if present, else falls back to his Household E-mail. However, the fields labeled Household E-mail and Household Phone are still present, and they should contain exactly what they contain on their corresponding input screens.

And the Membership.csv export file should definitely respect the user's raw data input, since it is designed to be consumed by a program rather than just be a human-readable report. That program (or spreadsheet, etc.) can always apply its own if-then-else logic.

As things stand now, it is not possible to export from MLS the simple data just as users put it in. And if a single person or couple deliberately leaves the Household field blank, it will not stay blank unless the head of household leaves his own Individual field (phone or email) blank.

The closest representation of simplicity is on the website, which is not (yet?) infected with this wrongheaded logic. But that difference is clouded slightly by other factors, such as timing and other settings within LDS Account itself, which can affect a few cases. Other than these exceptions, what we see on the website's detailed profile seems to be what the user put in. If the user (member or admin) chooses to leave the field blank, it stays blank. (This is not the same thing as unchecking it's privacy box to suppress display, which is a separate function.)