Document User<>Contact Mapping

To discuss: how a Drupal User can manage multiple CRM Contacts and whether/how that relates to CRM User.

Best practice for security is one login (Drupal User) per human who needs to log in. I propose that we design against "organizational" Drupal User accounts.

In addition to tracking that a Drupal User and a CRM Contact represent the same human, we will eventually need a way for a Drupal User to manage any number of CRM Contacts for which they are authorized.

The diagram linked in #6 didn't convey. Perhaps the wrong share link?

I would argue that changing an existing linkage (changing either the User referenced or the Contact referenced) would be a fairly infrequent action to take and it would be acceptable or perhaps even wise to require that the CRM User be deleted and a new one created. Thus I suggest that both those fields not be editable after creation. However, I think a read-only indication of the referenced User and Contact would be helpful context.

The current set of fields doesn't lead to any reason to "edit" a CRM User entity and thus I wouldn't think revisioning would make sense.

However, if there's a reason for CRM User to be fieldable, then I would argue that it should be revisionable to capture the history of whatever field values change.

If there's nothing to be edited (i.e. no reason to be fieldable) then I'd propose removing the "changed" field.

Ugh, organization logins... I propose that we say that one needs to delete the existing mapping and create a new one.

It's possible a good use case for making User Contact fieldable comes along at a later date. If we were to make it fieldable in the future, it would simplify things to say that the Contact and User references cannot be changed (doing so could cause problems for future use cases' fields, which might assume this).

Merging...

I have encountered the following with my neighborhood association (ZNA) probably a dozen times:

1. Someone new to ZNA pays dues on our payment processor's hosted form
2. Zapier looks up the contact by email or, failing that, by exact name match in our accounting system, Xero (de facto CRM), and doesn't find them
3. Zapier causes a contact to be created for this person in Xero
4. The following year that person pays dues the same way but with a different email address (and slightly different name)
5. Zapier causes a second contact to be created in Xero
6. At some point I discover this and merge the contacts

In Drupal CRM / Member Platform, something similar could happen if the person isn't required to log in first (e.g. to optimize for collecting the dues), but in addition to the two Contacts (Contact A and Contact B), there could be two Users (User A and User B) and two User Contact mappings. At least one User Contact would need to be deleted. If the other one "needs" to be edited because the desired merge result is to keep User A and Contact B, I think we could adopt the same stance I propose for the organization login case: delete and re-create the User Contact entity.

In summary, I propose:

• Not fieldable
• Not editable
• Not revisionable
• Remove changed base field

Easy enough to re-add those things later.

For Member Platform, there was discussion of providing the ability to set each (Contact/Person) field as required/optional/hidden for each of A) user registering; B) user filling out a secondary registration form; and C) user editing their (Contact) profile. For editing, perhaps required/optional/disabled/hidden.

The "Secondary registration form" idea is about prompting the member for additional information after they provide the minimum information during registration. For example, only require email address for initial registration, but, once that's captured (and possibly after email is verified), require additional fields (e.g. name) to complete registration.

This would facilitate, for example, asking a member "What do you expect to get by joining this group?" during (secondary?) registration, but not exposing it to them thereafter. Or not letting them edit their name after registration.