Custom member fields

[Mikerowaved]

Aside from the fact that by labeling our Brothers and Sisters as Do Not Contact (DNC) we, the Clerks, are essentially passing judgement on them and assigning them to execommunicated or disfellowshiped status without a Bishop's Court.

I'm sorry, but I don't see the connection. People may ask to be excluded from publicly exchanged documents (i.e., Ward directories) or not have HT/VT for any number of reasons and the Bishop is bound to honor these requests. The clerk has no say in the matter and certainly is not the one "passing judgment".

If you have people in your unit who do not wish to be included in Ward directories, printing them directly from MLS is rather difficult and that's why it's been recommended that these lists be printed from the Local Unit Web Site (LUWS) instead. There, a box can be checked by anyone wishing to be excluded from public lists (or by an administrator in their behalf). Their names will simply be missing from the list instead of raising an eyebrow or two with Ward members because their phone number printed out as "Bishop Contact Only".

Finally, I know you were just trying to make a point, but those who have fallen into disfellowship or excommunication need our love and support more than ever and it should never be assumed that these (hopefully temporary) conditions be automatically equated with "Do Not Contact".

[russellhltn]

There, a box can be checked by anyone wishing to be excluded from public lists (or by an administrator in their behalf).

Unless something has changed, only the LUWS admin can do that. (And that's only for LUWS.)

The only things individuals have control over is "Show your e-mail address in directories and lists".

[greggo]

Unless something has changed, only the LUWS admin can do that. (And that's only for LUWS.)

The only things individuals have control over is "Show your e-mail address in directories and lists".

And if I"M not mistaken, the name still shows up (but without contact info).

[RossEvans]

Aside from the fact that by labeling our Brothers and Sisters as Do Not Contact (DNC) we, the Clerks, are essentially passing judgement on them and assigning them to execommunicated or disfellowshiped status without a Bishop's Court, I much prefer the label, Bishop Contact Only, or BishopOnly added to data field, Primary Phone Number.

I'm sorry, but I don't see the connection. People may ask to be excluded from publicly exchanged documents (i.e., Ward directories) or not have HT/VT for any number of reasons and the Bishop is bound to honor these requests. The clerk has no say in the matter and certainly is not the one "passing judgment".

I think this discussion is conflating two different concepts -- some form of "Do Not Contact" flag, and some method of excluding certain persons from published directories. A member could be in one group and not the other.

For the latter purpose, I wish the Church would create functionality in MLS that would faciliate this suppression, and would populate the flag in the MLS extract files as well. This would be consistent with policy and practice that honors members requests to keep their contact information from being generally published in a directory. It would not, however, affect all the routine reports generated by MLS for leaders and members to use in performing their callings (including HT/VT assignments).

But "Do Not Contact" typically means something different. It means "I don't want you to calll me or send anyone to visit me." Local priesthood leaders often must find ways to minister to such members with special care, and that ministering often means some calls or visits whether the member likes it or not. But there is no such designation recognized by the Church generally, and implementing such a flag in MLS would have to be driven by some novel new priesthood policy.

And from a systems point of view, neither status should be recorded in the phone or contact fields. That is just sound database practice. Phone number fields should contain phone numbers and not free-form notes. To the extent that such flags are needed and authorized by the Church, they should be progammed explicitly in dedicated fields. The next best thing, under the exisiting MLS design, is to use custom fields.

[Mikerowaved]

Unless something has changed, only the LUWS admin can do that. (And that's only for LUWS.)

Thanks for the correction, Russell.

And if I"M not mistaken, the name still shows up (but without contact info).

No, once flagged, they don't show up at all for regular users in any of the various output methods.

I think this discussion is conflating two different concepts -- some form of "Do Not Contact" flag, and some method of excluding certain persons from published directories.

I believe, tw.lbean was looking for a way to exclude certain members from a published phone list.

[russellhltn]

And if I"M not mistaken, the name still shows up (but without contact info).

Depends on what the LUWS administrator selects. The choices are:

• Do not show anything about this Family on the Web site
• Do not show home address
• Do not show telephone number
• Do not show spouse's name
• Do not show children's names

These can be checked off in any combination except for "Do not show anything" which automatically checks all the other options.

Note that the administrator has no control over just the email address itself. Only the member can do that.

[RossEvans]

I believe, tw.lbean was looking for a way to exclude certain members from a published phone list.

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.

[lajackson]

Unless something has changed, only the LUWS admin can do that. (And that's only for LUWS.)

The only things individuals have control over is "Show your e-mail address in directories and lists".

The member also can change their preferred first name. For all other changes, the member must: "Click Feedback to contact your administrator if you do not want information about yourself or your family to show on this page."

The Admin does the work.

We had one bishop who required his admin to hide every member in the ward before the site went active for our stake, then to unhide them as members opted in. It was a lot of work. But he did it. (We held off going active as a stake to give him a chance to contact most of the members and not have to hide them all.)

The new bishop has them opt out.

[dwterry-p40]

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

• A custom fields does not exist until you create it (System Options | Members | Custom Fields)
• A member does not have a custom field until you add it to his/her record (Membership | Custom Member Fields | (member) | Custom Fields | Add)
• A custom field does not have a value unless you give it one at the time you add it to the member's record

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

The custom report will completely ignore all other members for whom you have NOT added the flag to their record. So if all you do is create a flag (system options | members | custom fields) and you never add the flag to any members, then none of the members will show up in a custom report that uses the flag regardless of whatever criteria you attach.

One possible suggestion for a future enhancement would be to create a criteria called "exists" or "does not exist". An "exists" or "does not exist" criteria would function more like what the OP originally thought should happen. Selecting "does not exist" would find all members for whom the flag had not been added. Exists would find all members for which the flag was added to their record (essentially, if you combined the results of "has a value" and "has no value" together into one report, it would be the same as "exists").

[aebrown]

One possible suggestion for a future enhancement would be to create a criteria called "exists" or "does not exist". An "exists" or "does not exist" criteria would function more like what the OP originally thought should happen. Selecting "does not exist" would find all members for whom the flag had not been added. Exists would find all members for which the flag was added to their record (essentially, if you combined the results of "has a value" and "has no value" together into one report, it would be the same as "exists").

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.