CRM Core integration

[jonathanjfshaw]

The porting of CRM Core to D8 is being pushed forward again in the last week by MD Systems. As this will likely be the first CRM to mature in D8, and these guys are the biggest Drupal contributors after Acquia, and its intrinsically a modular and flexible system, it seems likely that CRM Core may well be the most popular system in Drupal's future for managing people.

Managing people is something that you have to deal with in the RNG ecosystem as well. In fact, CRM core in D7 has an extension CRM Core Event for managing events (porting to D8 not started it seems). Do you have hopes of integrating with CRM Core? It would be nice for there to be less competing modules in D8 for people & event managing.

[dpi]

Do you have hopes of integrating with CRM Core?

I dont have any feelings either way since I have not used CRM Core. I am certainly not against integrating with them. I am happy to consider any API changes or additions. RNG is quite a flexible module, and may not need more than a shim module for them.

[mirodietiker]

I see a bright future coming. ;-)

Porting the events module is far off a minimum viable product for CRM Core Drupal 8. Priority is definitively making it a pluggable framework and not pushing custom CRM specific features. That perfectly opens the opportunity to benefit from other projects, including rng for event management and drop complexity in our ecosystem. (My personal opinion and not discussed among other maintainers.)

[dpi]

Thanks for jumping in @mirodietiker. Let me know if you need anything from me or want to know more info. Im always on IRC. I understand you may be using Relation for CRM Core. I initially ported Relation to D8 for the purposes of this module, and decided to go with Dynamic Entity Reference. You may be able to get some inspiration from RNG for your data model.

[jonathanjfshaw]

I raised an issue for Redhen also to explore their collaboration with CRM Core and RNG along the same lines: https://github.com/thinkshout/redhen/issues/63.

[jonathanjfshaw]

I've looked at RNG more closely and I understand more what @dpi said, that integrating RNG and CRM_Core should be easy.

Registrants in RNG can be of any entity type that has been declared to RNG as suitable; the user type if supported out of the box, and the contact type added by the optional identity module. There is a configuration UI in RNG to select which of the declared entity types to use as the registrant for events. So registering CRM contacts should just be a matter of offering up CRM Core contacts to RNG as an additional option that can be selected there.

There'll almost certainly be some additional features desired over time, like a nice view of booked events for a contacts dashboard, etc., so a simple CRM_Core_RNG module will likely make sense as a home for any features that emerge.

Am I right in thinking that the entity types that can be used as registrants for events in RNG is determined by the IdentityChannel plugin defined in the courier module? In which case we would need to create simple logic for CRM core contacts similar to that in dpi/identity/identity_contact/src/Plugin/IdentityChannel/CourierEmail/IdentityContact.php ?

The tricky part is providing elegant handling for cases like "a user wishes to register someone else, and the person being registered may or may not already be a CRM contact". This gets into the use of CRM Core matchers to determine if the registrant is a new contact or an existing one, and logic to create new contacts if necessary. How does identity handle these kinds of duplication issues?

[dpi]

Am I right in thinking that the entity types that can be used as registrants for events in RNG is determined by the IdentityChannel plugin defined in the courier module?

You are correct. Its a simple Courier glue plugin maps the identity type to a channel (email, sms etc). Usually 1-3 lines + Drupal plugin boilerplate and annotation.

May or may not already be a CRM contact

To allow the new identity type to be referencable it needs to implement a entity reference selection plugin within the "rng_register" group. See \Drupal\rng\Plugin\EntityReferenceSelection\UserRNGSelection for an example. The workflow for creating new registrants inline needs some love.

[mirodietiker]

Determining entity types that can be used as registrants for events in RNG by using IdentityChannel from courier sounds odd to me... We are also looking into courier, but CRM Core also needs the concept of generalised identity and depending for something like this on courier feels wrong.

Matching in context of guests is a huge challenge. Guests can be created as contacts, but merging with any existing contact contains risk of polluting data. We thus have the idea of a moderation queue where insecure matches can be proposed for manual review and trigger a process when merged. Not sure when we will look into that though. The requirements are widely varying and i will need to look into this topic to understand the effects.

[dpi]

Determining entity types that can be used as registrants for events in RNG by using IdentityChannel from courier sounds odd to me

I could have created some kind of registry which allows you to flag an entity type as a identity for RNG, but it makes sense for RNG since usually an identity has a form of contact. Its making use of pre-exing systems.

I'm open to hearing alternatives, but as the solo developer on the project I couldnt concoct any other use cases.

Theorizing that the CRM Core contacts are made into RNG registrants: If a CRM core contact was made a registrant of a registration, shouldn't there always be a way of contacting that registrant. Beit email, sms etc. For sending registration confirmations, reminders etc?

It looks like you have both spent some time looking at RNG/Courier internals. Again, I'm open to discussions on IRC to help avoid you digging around on your own.

[dpi]

I have some identity consolidation notes for Courier that I want to implement. For example upgrading a contact (ldap, crm, etc) into a different identity such as a full Drupal user. This would be done by notifying code relying on Courier identities to change their references. etc.

Not sure if that helps you.

[jonathanjfshaw]

If I understand right, using courier as the identity provider requires that guests always have a contact method? I don't think this is ideal.

Firstly, it complicates the process of booking a group of people. If you're booking a group of friends for a concert, it's a hassle to look up and type in all their emails. There are plenty of possible use cases in which the event organisers only want to know guest's names, and don't need to contact them. Secondly, there are situations like children where guests may not have contact details, or like surprise gifts where we really don't want the guests to be contacted.

It looks like requiring contact details for guests may impose an inflexibility on RNG that would be annoying in some use cases. The issues aren't necessarily fatal - users can fudge around them - but it's not the best user experience.

[jonathanjfshaw]

Matching in context of guests is a huge challenge.... i will need to look into this topic

@mirodietiker, the CiviCRM manual has a clear but thorough section on this subject, discussing the features they offer for this. It may be useful research when you get into this area.

[dpi]

that guests always have a contact method? I don't think this is ideal.

@jonathanjfshaw in this instance, the entity type doesnt actually need the value of the email. but should at least have a field for it. If there is no value then notifications dont get sent.

[dpi]

RNG 1.3 introduces inline registrant creation, and an alternative contact entity in RNG Contact: #89