| jdleonard |
At the end of our extended working session immediately following last week's Zoom call, we were discussing the Event module spec |
| jdleonard |
One question that came up was about event "locations" and whether to solve for the use case of a site using the same locations for its events and having a concept of a reusable event. |
| jdleonard |
Clearly that's something that Member Platform needs to solve for (even if not for 1.0), but the initial question is whether this should be solved by the more generic "Event" module. |
| jdleonard |
Should the Event module provide an Event Location entity type? A location type (bundle) could be created for online events, another for in-person events, and another for hybrid events. (edited) |
| bsnodgrass (he/him) |
I think it depends on the definition of a “reusable” event. The Event platform should solve for the case of a multiday event with sessions. To keep it simple, I think an event should be defined as a singular event that happens at a particular time. It could support multiple locations including in-person, online, or hybrid.Expanding on that, If multiple locations were supported that would solve for the case of something like Eastern Timezone, Hybrid which includes multiple user groups joining in.Is the goal to easily add an event based on a previous one, we could maybe use an additional module in the platform to allow for duplicating the event. |
| jdleonard |
Two clarifications to avoid confusion for those not fully onboarded here:Not discussing a "reusable event", but rather a "reusable location""Event Platform" is a separate project(edited) |
| jdleonard |
I like the concept of an event supporting multiple locations. Presumably each location could each have its own timezone, but the time at which the event takes place shouldn't change (apart from adjusting for timezone) or we encounter too much complexity. |
| jdleonard |
If an Event's "format" is "in-person" that could allow any number of Event Locations to be added so long as the Event Location Types supports "in-person" Events. If an Event is "hybrid", that could allow any number of Event Locations to be added so long as the Event Location Types support at least one of "in-person" or "online". (edited) |
| jdleonard |
Support for recurring events add a lot of complexity, but I'd argue that that complexity should be solved for in the Event module ecosystem (if not in the Event project itself) so that a site's requirement to support recurring events doesn't preclude use of the Event module and its ecosystem. Thus I think we should provide some forethought as part of Event. |
| bsnodgrass (he/him) |
Thanks for the clarification JD.I agree with those thoughts… While I think it would be a nice to have to duplicate an existing event to create a similar one. We ought to have that be a feature request for later version. Having multiple locations would probably complicate that process. |
| jdleonard |
It needs further investigation, but after talking with @zengenuity, maintainer of Easy Email, I think we should use Easy Email for one layer of our email functionality. |
| jdleonard |
We'll need to build our own UI, but Easy Email can serve as part of the plumbing. |
| jdleonard |
We'll also need to contribute "email campaign" functionality (i.e. a representation of an email to be sent to multiple recipients as individual emails at a specified time in the future and with which additional information can be tracked e.g. open/click/bounce). |
| jdleonard |
Related:#3047786: Add email activity entities to track email history |
| bsnodgrass (he/him) |
Did you mean FLDrupalCamp in that description? |
| jdleonard |
Issue description is zengenuity's from 7 years ago 🙂 |
| bsnodgrass (he/him) |
yeah I didn’t catch that! |
| jdleonard |
Discussion about scheduled emails and email campaigns:#3050187: Support scheduled messages |
| mortona2k |
Email has been a hot topic lately. I’m on a project that’s wondering about service providers and Drupal modules for integration. Seems like there is a bit of recent change in this area.We don't need campaign emails, more like notifications triggered by system events. |
| bdanin |
Yes, we're likely going to use sendgrid_integration presumably with ECA |
| freelock |
I am thinking there are 3 entirely different "classes" of email to consider -- Individual/ad-hoc mail (e.g. a non-scheduled response to somebody's message, possibly an update about a particular event, might include both incoming and outgoing emails)- Transactional mail (standard event registration messages, reminders, renewals, commerce, etc - this is where Easy Email is a great solution, and mostly complete)- Marketing emails (e.g. the Mailchimp replacement - send a campaign message to a list) |
| jdleonard |
@freelock I generally agree.However, I think there are valid use cases to scheduling individual/ad-hoc emails. Maybe it's late and I want to (schedule a) reply to somebody's message in the morning. Or maybe I want to send an update about a particular event X minutes before the event.One could argue that even some transactional emails should be held to be sent during business hours. A less common use case for sure. |
| jdleonard |
Some organizations would probably prefer that the look and feel of emails across the classes be identical. Some might want there to be differentiation. |
| freelock |
sure, any of those 3 might want some sort of scheduling |
|
I think the difference is around how you compose a message -- the transactional mails you probably are not writing each individual one |
|
you create a template, and then you just decide when/how to trigger it |
| jdleonard |
Agreed! At least not every send. |
| freelock |
whereas an ad hoc email probably needs somebody to write, each time |
| freelock |
and a marketing one is probably going to be more than writing -- doing layouts, assembling multiple content items, etc |
| jdleonard |
Here's an odd use case I deal with: members request yard signs and, after dropping them off, in Mailchimp I "tag" the contact with "Has yard sign", which triggers an email (from a template) to be sent to them. Not sure whether to classify that as an ad-hoc email or a transactional email. |
| freelock |
I would think that could be a transactional mail |
| freelock |
anything you can create a template for, to send the same basic thing (with personalization) |
| jdleonard |
Yes, and... From a marketer's perspective, transactional emails are an (often missed) opportunity to sneak in some marketing. For example, you register for an event and the resulting email lists other upcoming events you might be interested in. That might require the feature set you mention for marketing emails, but at the template level. This kind of personalization is relatively uncommon, but could be quite powerful. (edited) |
| freelock |
I am thinking about the underlying architecture of easy_email -- config entities for each template, content entities for each email |
|
I think it would be fine to have dozens of email templates, for a wide range of emails you might want to send, or have easily available to send |
|
you can certainly have an "intro" field to inject some extra context into some of your templates |
|
But I'm thinking if you're doing marketing mails (mailchimp style) -- you wouldn't want to create a config entity for each one -- that strikes me as more content -- those could grow into hundreds or more, especially for things like a daily list |
|
you'd want those to be easy to compose, and associate with a list, a segment, a group, etc. |
|
whereas for the ad hoc email, those could actually start as either a marketing or a transactional mail -- one key difference is that it might be a reply to somebody's response -- a template for those might not make sense (although I guess there are cases where it might...) |
| jdleonard |
All good thoughts. To add confusion, I edit my yard sign email template just before delivering a batch of yard signs to make it relevant to the timing of the delivery (e.g. please don't place the yard sign until our next event is announced vs. please leave the yard sign visible until Thursday). |
| freelock |
I think of Easy Email as just an email template system, not really anything more than that -- so for transactional mails, that's great, but it doesn't really help with ad hoc mail composing, or your one-off highly designed campaign mail |
| freelock |
I could see a need to dump an easy email template into your ad-hoc email compose screen... |
| jdleonard |
In Mailchimp, the yard sign email is a campaign of type "automation flow". The email is edited the same way a "regular" email campaign is (same designer). Just sharing for context; not claiming we should do as Mailchimp does. |
| jdleonard |
Mailchimp "email templates", which we don't really use (it's easier to just duplicate the last email we sent and edit) can be of type "Marketing" or "Transactional". Our account isn't set up for transactional so I don't know how that changes things. |
| freelock |
I do think we should be looking at those -- is that a sequence of mails you can set up to go at certain times? any sophistication in there we should consider? |
| jdleonard |
Mailchimp marketing "email templates" are either Mailchimp-provided templates that you can customize (supports their fanciest drag and drop editor) or custom HTML templates (supports only a more basic editor). |
| bdanin |
https://www.drupal.org/project/easy_email
This seems good for templates
However it's not an email service provider. Looks like Symfony mailer might provide that. And ideally you plug into a server system with good deliverability, not just the web server.
That's where sendgrid comes in I think. Or any other email service provider. MailChimp is more one stop I think, it's also the template builder. You can push RSS or similar feed to MailChimp for automation. |
| jdleonard |
There are some notes jotted down in Composing and Sending Emails that need refinement. We're working under the assumption that an email service provider (like Sendgrid, Mailgun, or Mailchimp Transactional) will be used. I'm bringing up Mailchimp as an example of marketing email features that we might build in Drupal. |
| bsnodgrass (he/him) |
For CRM Membership and CRM in general. Adrian and I are installing CRM on FoxValleyDrupal, and I think we can rope @Bluegeek9 and/or @bluegeek9 (he’s been duplicated) into working with us on that implementation. I’m sure we will get some ideas from that effort. (edited) |
| jdleonard |
+ @Steve Ayers, who for some reason has three Slack accounts... |
| jdleonard |
https://www.drupal.org/project/crm_membership |
| jdleonard |
Important architectural discussion (thoughts please!):#3583135: Use relationship type instead of dedicated field |
| mortona2k |
I am very interested in this atm. Need to be able to have crm contacts pay for an account and become a member. |
| mortona2k |
This looks like the issue for that:#3580081: Integrate: Commerce |
| bdanin |
we need recurring subscriptions for members, annually renewed with a stripe payment integration.we need email reminders sent out 2 months (might change) before the membership expiresand then give 2 weeks post-subscription payment due date before the membership is marked "inactive" or similar type of flagpretty standard type of annually paid membership consideration |
| mortona2k |
Does anyone know the status is on this one? https://www.drupal.org/project/crm_membership_commerce |
| jdleonard |
@svendecabooter |
| jdleonard |
Note that the CRM issue to integrate with Commerce is more general than membership-related needs. Modules that want to provide payment integration for memberships (e.g. CRM Membership Commerce) should integrate with CRM Membership. |
| jdleonard |
However, it's a little premature to do so as CRM Membership doesn't have any releases and its architecture is subject to change. |
| mortona2k |
Great, I think we'll need both of those. Happy to collaborate with anyone more familiar with the commerce ecosystem so we can get the foundation right. |
| mortona2k |
I have some some pretty complex commerce work, but it's been a few years and I haven't been following the latest releases. |
| jdleonard |
Suggest starting with this issue:#3583135: Use relationship type instead of dedicated field |
| mortona2k |
I am trying to understand, but it's fuzzy for me. My sense is that this is about consolidating architecture with how crm contacts use a relationship entity? |
| mortona2k |
I'm looking at the Membership entity code. Is this saying that the fields need to be implemented here, similar to how CRM's Relationship entity works? |
| mortona2k |
Here's the membership add form.I think this highlights the issue. Simpsons household is a contact type. There isn't really an organization entity yet. Membership should take the place of that? |
| mortona2k |
Should household/org not be a type of contact, and be a standalone org type instead?Or is Membership really a special kind of Relationship between contacts? |
| mortona2k |
Here's the simpson relationships.If the Membership entity references a relationship instead of the two contact fields it has, is that enough? |
| mortona2k |
Relationships are between two contacts. Membership seems to include multiple contacts. |
| mortona2k |
I have a pretty good handle on the issue now. Using CRM Relationship instead of the current fields makes sense.I'm a little unsure how the Relationship is linked to the Membership, seems like a ref on Membership to Relationships makes sense.The remaining concerns are mostly around audit logs and the ux. |
| svendecabooter |
The CRM membership commerce module is assuming the basic API for CRM membership wouldn't change. I needed it for a client so I released it. If the architecture of crm_membership changes, I would need to reevaluate the module. |
| svendecabooter |
But I'm running forked versions of both modules now, since my client work needed to move faster than contrib does, so not sure I will have time to untangle it again |
| mortona2k |
@svendecabooter this is an excellent proof of concept!I would like to sync up with you on what you needed to change and help think about how to build a stable foundation. |
| mortona2k |
—For the target 1.0 member platform (meetup clone), I think there are two distinct kinds of membership. One is a paid meetup.com account, that grants you access in the system.Another is being a member or admin of the meetup groups.Should both of these be handled by a membership system, or is the first more related to role/user account?I am thinking that the membership period and renewal rules is what overlaps. (edited) |
| jdleonard |
My $0.02: Member Platform 1.0 doesn't require CRM Membership. We've said we can consider all Contacts as members for 1.0. However, if CRM Membership is ready and easily usable, I think we'd adopt it for 1.0. |
| jdleonard |
Also note that we're supporting a single organization; not multiple groups. |
Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Comments
Comment #2
jdleonard