Closed (fixed)
Project:
Member Platform
Version:
1.0.x-dev
Component:
Meeting
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
12 Nov 2025 at 04:48 UTC
Updated:
19 Dec 2025 at 04:34 UTC
Jump to comment: Most recent
0️⃣ Who is here today? Please post your Drupal.org username if you have one. We provide issue credit for those contributing to the meeting beyond this thread. Especially if this is your first meeting, please mention a club, association, meetup group, non-profit or other membership organization (MO) you think could benefit from this initiative and/or tell us why you’re joining us.
| jdleonard | JD Leonard (jdleonard). I recently had a discussion with another neighborhood association about starting a nonprofit to offer Member Platform to NAs in Austin... |
| paulmckibben | Paul McKibben (paulmckibben) - Atlanta Drupal Users Group |
| richgerdes | Rich Gerdes (richgerdes) - Event module maintainer and DrupalNYC |
| James Shields | James Shields (lostcarpark) |
| beautifulmind | Beautifulmind |
| svendecabooter | svendecabooter |
1️⃣ Do you have any topics to propose for the meeting today? Open your own thread in the next numeric order or reply to this thread and I'll do it.
2️⃣ Mockups for Member Platform
| jdleonard | Here's what's in our Balsamiq account so far (thank you @James Shields)! https://share.balsamiq.com/c/jsZ5FzqTnS72ok1jTirdjE.jpg |
| James Shields | I had a useful chat with @estevenson yesterday, and we went through the mockup notes. I'm going to work on combining those with Bee's original mockups in Balsamiq over the next few days. |
3️⃣ Generalizing Entity Registration to allow any entity type (i.e. Contacts) as registrants
| jdleonard | @richgerdes would you please summarize what you've done to date and what the next steps are? |
| richgerdes | I've looked at the registration module, and began working on trying to merge the implementations in[#1653458]#comment-16352934@John Oltman and I are meeting this afternoon to plan how we want to implement the new version of this and handle things like the anon registration. |
| jdleonard | What's the set of information that must exist for an anonymous registrant (in the most general case)? A name/label? |
| richgerdes | Currently the registration module will automatically link the current user (or let them select another user) during registration. For anon, it will show an email field. This is required because there are a number of features in the module around being able to contact a registrant, like sending email, and such. If we are registering other entity types, we need to figure out how to replace this functionality (or if its in scope for the module or a sub module) |
| jdleonard | For Member Platform, we've discussed the need to have registrants without an email address (whether a CRM Contact or a +1 with/without further information like their name). |
| richgerdes | yeah, my plan would be to support registrations without emails. We just have to determine how to handle anon I suspect we will have a plan later today. Can update here then |
| John Oltman | I have a call with Rich later today to iron out the approach for registrations without email addresses and registering entities of any type. |
| John Oltman | @jdleonard we talked and Rich is going to start on a new submodule of Registration to enable any entity type as a registerable entity. And it may also handle the "no email address" use case, TBD. |
| jdleonard | @John Oltman Do you envision a need for a new major version of Entity Registration to support this, or is the idea to avoid doing that? |
| John Oltman | @jdleonard for now Rich and I are trying to avoid that and take a shorter path. But a rewrite of Entity Registration, to address multiple needs, is probably inevitable. |
| richgerdes | I think there is a phase 1 and phase 2 to this. Phase one will be to add a the feature as a submodule in the registration project. Phase 2 will come after that to see if it benefits us to merge the features in a 4.0The downside of a new version which reworks the base module's expectations is that it will make it hard for existing projects to get continued support |
| jdleonard | That makes sense, thanks y'all! |
| jdleonard | @richgerdes Any significant challenges for Phase 1? |
| richgerdes | I don't think so. I think we have a plan which should work. Probably going to have a few rounds of updates until we get it working, but I don't foresee any major issues |
4️⃣ CRM Event spec
| jdleonard | @estevenson Would you please summarize what you've done to date, any blockers, and next steps? |
5️⃣ CRM's use of Primary Entity Reference
| jdleonard | CRM uses the Primary Entity Reference module for its Email / Phone / Address reference fields on a CRM Contact. @Steve Ayers asked me to evaluate compatibility with common Drupal modules that are known for leveraging core's Entity Reference fields. The results of my analysis are here. Do we feel comfortable with continuing to use Primary Entity Reference? Or do we want to consider creating a novel field formatter for core Entity Reference, which then wouldn't require additional integration work? See this issue for background. |
| svendecabooter | Using a dedicated field type does indeed require extra work to integrate with different Drupal ecosystems, which might end up triggering limitations further down the road.I have the same experience with using https://www.drupal.org/project/custom_field in a bunch of projects. While I'm a big fan of that module, it does require extra integration work from time to time (luckily the maintainer is very responsive in that regard).A "field formatter for core Entity Reference" solution would then by convention assume delta 0 is the primary reference? The field formatter would just account for indicating that convention visually? |
| jdleonard | Yes, that's the idea. It would be helpful if we had a realistic visual design to consider for such an approach. |
| Steve Ayers | Having a primary is important for sending communications. Primary Entity Reference inherits from core's Entity Reference. There is more work in the sense that it is not zero. The widgets and formatters also inherit, so I have found it pretty straight forward. Custom Field looks interesting, but I am not sure it is the right solution. |
| svendecabooter | custom field example was just to indicate that using a non-core field type requires extra work most of the time 🙂 |
6️⃣ Migration from CiviCRM to Drupal CRM
| jdleonard | Any progress to report @Scott Wolpow? |
| Scott Wolpow | Not yet. Stuck on a client issue moving from multisite to single site |
7️⃣ Calendar invites for our meetings
| jdleonard | DM me with your email address to be added/removed from the calendar invites for our Zoom and Slack meetings, which alternate weekly. |
8️⃣ Representation of Event (and the Events recipe)
| jdleonard | We recently discussed the possibility of using the Event module to standardize on an entity type that represents an event. |
| jdleonard | @John Oltman also asked about the Events recipe and we said we wouldn't rely on it because modules can't depend on recipes. |
| jdleonard | We said that perhaps it could make sense for the Events recipe to (in a later version) depend on the Event module. cc @mandclu |
| mandclu | I don't think most sites (certainly the ones I've worked on) have really needed for events to be anything other than nodes. What's the perceived need for MP? |
| John Oltman | @mandclu I suggested that as a possible future state because an Event content type on its own is just a label - it is not really "event aware". The Event entity type brings that awareness with it. It knows about dates and scheduling etc. |
| mandclu | I think this could use more clarification. I don't really understand what you mean by "event aware" |
| mandclu | Maybe the Event module aims to be more like what Event Platform is built to provide? |
| John Oltman | yes i suspect there is a lot of overlap between the platform and the goals for the module - ideally the community (us and anyone interested in events) would try to avoid duplication - i will discuss with richgerdes later today - this is an area needing more exploration |
| richgerdes | The rational i have for using an entity type is you can't sub type events.For example, I see a conference as different types of events. The main conference, the submits, the key notes, lunch, social gatherings. Using a single event node type creates more work on the side builder to classify, organize, and configure the specifics of each type of "event". If you have an "Event" entity type, you can have bundles for "Conference", "Submit" "Key Note", etc, build a tree that manage the event. Each event bundle can then have specific fields, views, review processes to manage its information.I think that an "event" "content type" is good for a company website that just want's to manage a range of events, but for an event platform with a set structure, having a dedicated entity type gives you some guardrails and defaults. I don't think we necessarily need to agree on one solution for the community. The question is what makes the most sense for a member organization? |
| jdleonard | +1 to fieldable event sub-types, which feels like a powerful mechanism. While Member Platform would undoubtedly start with a single Event Type, I could certainly see use cases for having more than one. |
| jdleonard | @mandclu I think (correct me if I'm wrong @richgerdes) that the Event module now (as opposed to when it existed mostly for COD) aims to provide just the Event entity type. An ecosystem of modules would sprout around that. |
| jdleonard | I would imagine there might be a CRM Event Registration module that provides some glue around registering CRM Contacts for Events using Entity Registration. And that Member Platform would build on that with more opinionated functionality. |
| And perhaps Event Platform might be able to leverage Event sub-types, etc. etc. | |
| mandclu | I can can see pros and cons to using a separate entity type for events. For example, it becomes more complex to include event entities alongside other kinds of content (e.g. news, etc) in views, and so on. And there's no reason you can't have more than one content type for events, with different fields, and update views to include all the relevant types in your calendars, lists etc |
| jdleonard | In my mind, the real power here is in facilitating an ecosystem around the Event entity type that many event-related use cases can contribute to and benefit from. I think this is more powerful than a solely recipe-based approach (though I would expect recipes to benefit from it as well). |
| jdleonard | I take your point about a View listing multiple content types. I can think of some roundabout ways to address that, but none are ideal. |
| jdleonard | I can imagine use cases for having events that don't necessarily have the baggage of a content type (e.g. sync event data from external sources). |
| mandclu | I doubt there's one solution that will always be better for everyone's use case. Maybe for member sites the dedicated event entity type is better, but there has been significant uptake for events as nodes. At a minimum, I don't foresee updating the Events recipe anytime soon |
| richgerdes | There are definitely down sides to mixing entity types, in any scenario. For example, products can't be cross listed with pages in views either. I don't think that's necessarily a reason to not have an entity type for events. I personally feel like node types are often over used though, and there are cases when a custom entity type would provide a better experience. IMO, nodes really work best for public content pages and once you start adding additional functions around it, it becomes a little messy.Definitely not one solution that will be ideal for all possible sites, and I think in contrib, both options should be supported (which is the plan for the updates to entity registration, and that work won't lock you into any specific event type). We'll have to see if member platform benefits from a specific implementation |
| mandclu | I agree about the overuse of content types, particularly for content that isn't meant to be accessed directly. That's a big reason I created the Storage module, but I can see where a purpose-built entity type can have benefits.Event Platform actually uses taxonomy terms for time slots, partly because Views natively has better support for terms as contextual filters than any other kind of entity, out of the box at least. |
| richgerdes | Yeah, calendaring in Drupal wasn't straight forward the last time I checked. The terms seem like an elegant solution though |
9️⃣ Weigh in on the direction for Contact Type fieldable sub-types
| jdleonard | https://www.drupal.org/project/crm/issues/3557244 |
| svendecabooter | How would that work technically?Profile entities are bundleable via Profile Types - CRM Contact entities are bundleable via Contact TypesI don't immediately see an option in Profile to have subtypes for the profile types?That seems kind of complex to build with the Drupal entity system? :thinking_face: |
| Bluegeek9 | Yes, how would this work? |
| jdleonard | Profile allows profiles of various types to be attached to a given User. Conceptually, we could have a similar pattern with something of various types that gets attached to a Contact. I haven't worked out the technical details, but it seems like an analogous problem? |
| svendecabooter | that would rather be various contact entities of varying type, that get attached to a User entity then... |
| svendecabooter | Oh I see... it would probably involve another bundleable entity then - that can be linked to the Contact entity...Say "ContactProfile" for lack of a better term...[Contact entity of type Person] |_ [ContactSub entity of type Customer] |_ field customer_id etc... |_ [ContactProfile entity of type Volunteer] |_ field volunteer_id etc...(edited) |
| jdleonard | Yes, that's Profile's approach, which I think could work well. Open to other solutions to the problem! |
| Steve Ayers | I hate to be the one to point out that customer_id and volunteer_id are related to another contact; whichever organization the person is a customer or volunteer. |
| jdleonard | Let's pretend there's no ID in the above example. |
| Steve Ayers | My point remains for any fields. whichever organization the person is a customer or volunteer. |
| Steve Ayers | What are the profile types you think might be included? Is there a strong overlap with the relationship types? |
| svendecabooter | Either way, I'm not sure this should be added to CRM core. Much like the Profile module, it could be an addon module |
| jdleonard | I agree that this might not belong in the base module (trying to avoid the term core to avoid confusion with CRM Core), but I think the ecosystem should support it. |
| jdleonard | I don't think any profile types should be included with this feature; just the plumbing.If we're seeking a more concrete example use case... Take a website listing home service providers, which can include Persons and Organizations, which can provide one or more different broad classifications of services (e.g. residential cleaning, electrical, plumbing). For each relevant category of service, a different set of fields should be associated with a Contact. There could be an individual cleaner (Person) who only provides residential cleaning services and has only those additional fields. There could be a large organization that provides all three of the example service categories I mentioned. (edited) |
| svendecabooter | I would implement such a case by creating a Service entity type with bundles (cleaning, electrical, plumbing,...) either through ECK (for site builders) or a custom entity in a custom module (for developers). On the CRM contact entity would be an Entity Reference field (with Inline Entity Form probably) to attach the specific Service entities to the Contact. |
| svendecabooter | So not sure if CRM needs to provide specific functionality to get this set up, other than documentation? |
| I guess a CRM addon module could be created that already provides a generic entity type for that purpose, which you can then "rebrand" for your purposes, eg give it "Services" label. I'm not sure if that provides much added value over ECK though | |
| jdleonard | There are of course multiple ways specific things could be built. One challenge with discussing a specific example is that there are always alternative approaches that could be considered. I think there is value in a general, standard, CRM Contact-aware solution to having different sets of fields for different Contacts. In particular, such a solution should handle access control for those fields in the same way that CRM handles access control for fields attached directly to a Contact (e.g. awareness of link between a Contact and its User and possibly other access control derived from the Contact's Relationships). We can't expect a site builder to handle that on their own with ECK.Let's (temporarily) call that generic entity type Contact Profile with configurable Contact Profile Types that can apply to specific Contact Types. That would allow a site builder to create different sets of fields (Contact Profile Types) that get applied to different Contacts (not necessarily having to do with a Relationship). Some "Plumber" fields (e.g. certifications) for Person/Organization Contacts that are plumbers, some "Volunteer" fields (e.g. types of volunteer work they're interested in, skills) for Person Contacts that are volunteers some "Cat" fields (e.g. cat breed) for Pet Contacts (imagine a Pet Contact Type) that are cats, some "Teacher" fields for Person Contacts that are teachers.Even if none of these specific examples resonate, does this approach make sense (regardless of whether it is in the base CRM project)? |
Comments
Comment #2
jdleonardComment #3
jdleonard