Custom member fields

[dwterry-p40]

I suppose that would work, but that seems needlessly complex. I fail to see how that would be any more functional than just fixing MLS so that "has no value" works as any reasonable person would expect it to -- it matches every record that has no value for a custom field, whether it has the custom field attached with a blank value or does not have the custom field attached.

The complication is that MLS does not exist in a vaccuum. There are already existing units with custom reports that count on this behavior ... that the custom report field does not exist except for members to which it has been added and that the field ONLY has (or does not have) a value for THOSE members (I know, because I have seen these reports).

So the addition of an "exists" (or "does not exist") criteria would solve the OP's request while leaving intact the other reports that count on the current functionality to continue working.

[rmrichesjr]

A few words of explanation about the usage of Custom Fields inside of a Custom Report:

...
So, if you create a custom field called Flag1 and want to create a custom report to access it, you will find that:

1) "has a value" only finds those members for which you added the flag AND entered text at the time you added the flag to their record.

2) "has no value" only finds those members for which you added the flag AND DID NOT enter text at the time you added the flag to their record

...

I suppose that would work, but that seems needlessly complex. I fail to see how that would be any more functional than just fixing MLS so that "has no value" works as any reasonable person would expect it to -- it matches every record that has no value for a custom field, whether it has the custom field attached with a blank value or does not have the custom field attached.

I'll second Alan_Brown's view. If "has a value" and "has no value" are ever equal, that's a bug and should be fixed. The two expressions should always be of opposite truth value.

[aebrown]

The complication is that MLS does not exist in a vaccuum. There are already existing units with custom reports that count on this behavior ... that the custom report field does not exist except for members to which it has been added and that the field ONLY has (or does not have) a value for THOSE members (I know, because I have seen these reports).

So the addition of an "exists" (or "does not exist") criteria would solve the OP's request while leaving intact the other reports that count on the current functionality to continue working.

I understand your concern, but people who rely on quirky behavior in software sometimes have to make adjustments when bugs are fixed. The number of people relying on this bug must be small indeed.

Regardless of the possible implementation of a "does not exist" criterion, it is simply unreasonable for custom reports to reject records with no custom field defined when the report criterion is "has no value". Such records have no value for that custom field and thus must be matched in any reasonable implementation.

[tw.lbean]

That's now the way I read his post. It began: "We have several ward members who have specifically requested to not be contacted by the ward at all."

That is not just about the published directory, but about all contact.

Whohoo!! Without realizing it (being new member of this forum), I've apparently opened a long standing issue with lots of feelings and even more opinions.

I actually want both - though when I posted originally, I hadn't thought about the distinction. We have members who have been visited and specifically request no contact from the ward. In other wards I've been in there were Senior VP types who would only give contact info to priesthood leaders because of the negative consequences of publicly revealing it. Seems both types should be accommodated in MLS.

I'm just the one doing the work attempting to magnify my calling, so I refuse to pass judgement on anyone for anything. I believe most (all?) clerks do the same.

I posted my view on a solution for MLS for this in another (probably dead) thread...

I think a simple way to deal with this would be to make available a "DNC" flag for members that is kept local to each unit. MLS would then pay attention to this flag when generating reports and such, but the next unit to receive the records would have no record of this flag.

This would enable those best equipped to minister to these individuals (the local priesthood leaders) with tools to help them do their work.

As a side note, I personally believe this is what I call a "balloon" problem. You squeeze a balloon in one place and it pops out somewhere else. In this case, you squeeze the area of "making no built-in support available for DNC members" and it pops out with things like hijacking database fields (like name, phone, etc...) to communicate this information.

Seems like the pragmatic option is to make available the tools, "teach them correct principles", and thus enable local priesthood leaders with tools to allow them to focus better on ministering to members.

I'm not an ostrich by any means. I realize the practice and execution of this is never perfect...

[lajackson]

I actually want both - though when I posted originally, I hadn't thought about the distinction. We have members who have been visited and specifically request no contact from the ward. In other wards I've been in there were Senior VP types who would only give contact info to priesthood leaders because of the negative consequences of publicly revealing it. Seems both types should be accommodated in MLS.

Three comments.

One. Although the numerical purists seem to disagree, I have always felt that Unlisted is a valid phone number, and have used it often in a previous life. After all, it is exactly the same length as 555-1212.

Two. I have always felt that the best way to deal with members who request no contact is to assign them to home teachers in a special companionship where those home teachers recognize the situation and make or do not make contact accordingly. This special companionship will usually have a more regular home teaching assignment as well.

Three. I add my vote that I think it would be nice for the bishop to be able to have a family flagged to not appear in the ward directory, just as is possible in LUWS. With that capability, I think there would also need to be available in MLS a list/report of flagged families, and a global unflag option to clear them all at one fell swoop.

When you wish upon a star . . .

[dwterry-p40]

I'll second Alan_Brown's view. If "has a value" and "has no value" are ever equal, that's a bug and should be fixed. The two expressions should always be of opposite truth value.

There are a total of FOUR states.

1) Flag exists
2) Flag does not exist
3) Flag exists with a value
4) Flag exists without a value

What you are suggesting is that #2 and #4 be equal. Here is the specific problem with that solution (which existed at one time, was reported as a bug by clerks just like yourself, and then fixed in version 2.5) and the reason why it makes sense to work the way it currently does:

If you create a DNC flag, you can simply add that flag to specific members who do not want to be contacted.

Now if you create a custom report that queries for DNC "has no value" using your suggestion, it will return EVERY MEMBER of your unit that you have not assigned the DNC flag to. Oops! Sounds like a bug.

You certainly don't want to have to add the DNC flag to every member of your unit (giving it a value of yes or no for example), because it would take a very long time to go to each member record and add the flag. So instead, the mere existence of the flag should be sufficient to tell you a member does or does not want to be contacted.

There are other uses where the flag is something entirely different. Where the value (the text the clerk types, or doesn't type) is what matters.

So the fix for this bug was to realize that there are four states. That the existence of the flag matters as well as does its value. They are two separate states and need to be treated differently.

And there you have your programming lesson for the day.

[dwterry-p40]

Just in case anyone is still confused about my answer, let's evaluate the DNC flag by expressing the logic in english:

if DNC exists - do NOT contact member
if DNC does not exist - okay to contact member
if DNC exists with a value - do NOT contact member
if DNC exists without a value - do NOT contact member

Now you can see that the EXISTS state of the DNC flag is what matters, not the value that the flag contains and that existing without a value is NOT the same as not existing at all.

[kd7mha]

There are a total of FOUR states.

1) Flag exists
2) Flag does not exist
3) Flag exists with a value
4) Flag exists without a value

there are only 3, item 1 is a parent of items 3 & 4

[jbh001]

Phone number fields should contain phone numbers and not free-form notes.

I disagree. Having a phone number listed as "Private" or "Unpublished" is a quick and valid way of communicating, "Hey, even if you find out this person's phone number, don't add it to the ward directory." That way if John Doe's phone number shows up in the printed phone book, I, as an unsuspecting ward clerk won't unwittingly change the blank field, or a field of all zeros or all ones or all nines, to the phone number from the phone book. "Unpublished" tells me that this person has requested privacy rather than that the information has been simply unavailable, and to ask first before changing anything.

There is no way to effectively communicate "Unpublished" or "Private" using numbers only.

Having said that, I would love to be able to enter in a phone number, and then have some check boxes off to the side like:

• Unpublished/Private
• Home
• Cell/Mobile

That way the number could be in MLS, but the Unpublished/Private checkbox would suppress the phone number on all (or most) printouts or replace it with "Unpublished."

[tw.lbean]

So the fix for this bug was to realize that there are four states. That the existence of the flag matters as well as does its value. They are two separate states and need to be treated differently.

I understand the logic presented. I disagree though because the help for MLS documents the behavior advocated by Alan_Brown and representing all four cases with additional options needlessly complicates the user interface.

I work in a user experience group in my professional life (and as a programmer of Flex/Flash content), but I bet most users are not programmers. The best option, in my opinion, is to limit the complexity of the options presented to them.

The bigger issue I see is that the existing behavior deviates from the documentation. This is particularly unfriendly to users (programmers or not).

I add my vote in support of the logic working as advocated by Alan_Brown (which is how MLS is documented).