Contact Detail entity type with Address bundle and stubs for Phone and Email

I'm asking the Member Platform team to dive into this during today's Slack meeting.

Taking phone as a simple(r) example, I went down a bit of a rabbit hole.

It's late so I'm going to need to come back to this later, but some quick-ish thoughts...

There are quite a few contrib projects that define their own phone field type. There are some contrib projects that provide validation and/or a formatter for the core telephone field type. I think we should leverage some of the existing functionality provided elsewhere in contrib by A) extending one or more field types, field formatters, and/or field widgets or otherwise ensuring we don't lose out and we don't reinvent the wheel; and/or B) using a paragraph or entity (see below) to allow wholesale use of an existing project's field type. Further analysis needed.

https://www.drupal.org/project/telephone_advanced
https://www.drupal.org/project/telephone_validation
https://www.drupal.org/project/telephone_formatter
https://www.drupal.org/project/telephone_plus
https://www.drupal.org/project/telephone_type
https://www.drupal.org/project/telephone_international_widget
https://www.drupal.org/project/phone_international
https://www.drupal.org/project/phonenumber

I'm increasingly wary of CRM using a field type that is essentially a bunch of fields related to a phone number, but that are quite a bit more than a phone number. More complex use cases could need to track data (that we aren't currently anticipating) about each phone number such that it would be beneficial for a phone number to be fieldable. We can't change the field schema later. While there are obvious downsides, I think we should discuss using a paragraph or defining an entity to capture the various data related to a phone number.

Additional things that might warrant tracking per phone number, whether as a field or a reference from some other entity to a Contact's phone number:

• Confirmation status (similar to confirming an email address)
• Opt-in/out
• Communication preferences
• Activity (e.g. calls or texts to/from)

I'm not suggesting that any of these should be tracked for 1.0 (or even necessarily in a future CRM release). Similarly, I think we should not track mobile carrier in 1.0.

I haven't gone down the rabbit hole for the other field types, but I plan to. I suspect I will come to similar conclusions.

[edited to reference Paragraph rather than Field Collection - doh!]

@mradcliffe, Yes I think it could make sense to split this issue, but perhaps it would be wise for us to first determine the overall desired approach as there are some analogous needs across the different fields.

@freelock Good considerations. I'm arriving at the conclusion that it might not be realistic for us to determine all the likely needs up front so it would be wise to make phone number related data extensible (i.e. a paragraph or entity type rather than a custom field whose columns are immutable).

A quick look at DANSE suggests to me that it isn't set up to handle non-User entities as first-class recipients. However, Notifier has documentation making clear that it does. I posted a message in the #danse Slack channel to confirm and will report back.

[edited field collection to paragraph...]

As requested by @bluegeek9 in today's Member Platform meeting, I'm going to prototype a CRM Contact Address entity type (or Storage Type) with an Address field, its integration with CRM Contact via Inline Entity Form, and plotting contacts' addresses on a map to illustrate the value of using the contrib address field.

Yes, good idea.

jurgenhaas, DANSE maintainer and Member Platform supporter, replied:

that's correct, DANSE currently is built to users as recipients. Thinking about it, extending that to entities as recipient in general, shouldn't be hard. So, if DANSE otherwise is appealing, I'd be willing to make that enhancement.

We should probably move this discussion into a different issue.

Please see comments in the MR

Issue fork branch 3522243-map-demo (untested) contains the config I used to spin up a quick proof of concept of mapping Contacts' addresses. Here's a screenshot of that in action:

I look forward to reviewing! Will Views, ECA, Search API, Token, etc. be able to navigate the reference as they do vanilla Entity Reference or will they (each?) require additional integration work?

So far I haven't been able to find any evidence supporting your concern about simply treating the first referenced entity (delta 0) as the primary, but I'm seeking feedback from others.

Renaming this to focus on Address. Will create and link to follow up issues for Phone, Email, and other needs. Will be most helpful to get this MR merged to facilitate the follow-ups.

Added follow-up issues to IS.

Sorry I missed your question earlier!

Honestly I have not focused on permissions yet. I think the ability to create/edit/delete an Address/Phone/Email should be inherited from the ability to create/edit the Contact and it should only be possible in the UI via inline Entity Form. I created #3525361: Address/Phone/Email CRUD access control to follow-up.