Document CRM User

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.

Only individual contacts can be used with crm_user. There cannot be an organizational crm_user.

Access control of contacts is best handled with the group module.

Additional access control can be provided by something similar to node_access, crm_contact_access

I made a diagram I intend to add to /docs

https://www.mermaidchart.com/play#pako:eNqrVkrOT0lVslJSqgUAFW4DVg

Should crm_user be revision-able?

If so, I assume we want a new revision every time the entity is saved.

Should the user reference field only be on the add form, and absent from the edit form? If so, then only the crm_contact reference need be revision-able.

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.

I don't have a real use case for making the entity fieldable at the moment. I am thinking about custom event subscribers for when a user is created. The subscriber might need to store data there as part the create/look up.

Maybe it could be used to store a name format field; allow users to define their own Display name format. Yet, user_data is probably a better place to store the user's preference.

We should bring the fieldabilty to the group. They might have a reason to keep it fieldable

For being Editable, I am thinking about Organization logins. I do not like them, but there is nothing we can do about them. Users can only be mapped to a person/individual. So an admin might want to create a new contact and update the mapping when a different person takes over the account.

There is also the issue of duplicate contacts. When we build a de-duplicator/contact merger we might need to update the mapping as a result. I would prefer the merger have a bias for keeping contacts mapped to a user.

Links ✨ CRM User <=> Contact: Permissions Active

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.