Problem/Motivation

This issue is inspired by a question Michael Goldsmith (platypus media) asked me by email. I'll encourage him to post any additional thoughts.

The Contact Method Types Email address, Telephone number, and Address (let's call them "The Big 3") are treated specially compared to any other Contact Method Types a user creates.

The Big 3 have base (Primary Entity Reference) fields defined on the Contact entity type, whereas others require configurable fields, which must be added to the desired Contact Types and configured in a specific way to match the appearance and behavior of The Big 3.

There are use cases for not having The Big 3 on a given Contact Type. For example, an animal shelter might create a Pet Contact Type for which the Big 3 don't apply or make sense.

As a site builder, given a Contact, it's a bit tricky to get to all of the Contact's Contact Methods. For example, a view of Contacts has no one field that can be relied upon.

Steps to reproduce

Proposed resolution

At a minimum, we should document the differences between The Big 3 and other Contact Method Types, including how to have the others show up on Contact entity forms.

Consider replacing the existing base field definitions for the Big 3 with:

  • one base field definition that targets all Contact Method Types
  • one configurable field for each of The Big 3, attached to each of the default Contact Types

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jdleonard created an issue.

platypus media’s picture

platypus media commented

My thoughts on this issue stem from me playing around with the contact methods and trying to add a new method. I used "Social Media" as an example. I was able to create the custom contact method just fine, but it didn't show up in the contact mapping page. This led me to the discussion with JD that, in fact, the mapping page list of contact methods is separate and autonomous from the actual list of the contact methods.

There are plenty of use cases for creating contact methods above and beyond the "big 3." If someone uses Whatsapp, or any social media platform for communication- ie. DM me on instagram, etc. then it really stands to reason that while the default list of contact types is a good starting point, it really needs to allow for custom and arbitrary other contact methods. I think this will also resolve a bunch of other issues in the queue that suggest specific other methods to be added.

Adding a new method works just fine. The issue is on the mapping page. Therefore, my suggestion is a rethinking of how that list of contact methods is generated insofar as rather than them being hard coded, and having to add new methods to the user profile requires a bunch of extra steps including creating the "method" a second time in the profile and using an entity reference. That just seems like unnecessarily complicated steps for the user, and it would be a more elegant solution to pull the list of existing contact methods while the mapping form is being generated on the page load which will allow users to easily add custom contact method fields to the user profile.