Member Platform (Zoom) Meeting on November 20, 2025

Google Doc

You might find the Google Doc for this meeting (from which the notes are copied) to be easier to consume and to include additional detail (e.g. comments) not present in this issue. If this meeting hasn't happened yet, find and add to the agenda in that doc anytime before the meeting.

Member Platform Meeting

November 20, 2025 at 10:00am CST

Meeting Notifications, Agendas, Past Notes, Slack Channel

See [Meta] Member Platform meetings

Who is here?

Include your Drupal.org username in parentheses if you have one.

• JD Leonard (jdleonard)
• Bhavin Joshi (beautifulmind)
• Rich Gerdes (richgerdes)
• Scott Wolpow (scottwolpow)
• John Oltman (john.oltman)
• Erica Stevenson (speckles)
• Steve Ayers (bluegeek9)
• James Shields (lostcarpark)
• Eric Wheeler (sikofitt)
• Luke McCormick (cellear)
• Janice Chow (janiceychow)

What Topics Should We Discuss? / Limited Human Notes

• Recording
• Quick introductions
• Next week's Slack meeting will be on Tuesday, November 25 to avoid Thanksgiving Day in the US
• Wireframes
• What Relationship Types (e.g. employee, head of household) should CRM provide out of the box? In separate module(s) in the project / in different project(s)?
• Entity Registration and Member Platform / CRM
• Default values for CRM demographic fields
• Optional requirements working session immediately following the meeting

Action Items

• James and Erica to connect on wireframe requirements

Fathom AI Summary

VIEW RECORDING - 164 mins (No highlights)

Meeting Purpose

To align on Member Platform's architecture, key dependencies, and CRM's foundational structure.

Key Takeaways

• CRM's core will be lean, providing only essential building blocks (Person, Organization, Household contact types) to avoid bloat and enable ecosystem modules to define specific relationships.
• entity_registration will be refactored to support CRM contacts as registrants, a critical dependency for Member Platform's event management.
• Member Platform will use event module for its bundlable event entity and build a dedicated crm_event_registration module to bridge it with CRM contacts.
• Demographic fields will be included in CRM v1 as optional, reusable fields to accelerate prototyping, with a plan to extract them into separate modules or recipes later.

Topics

Member Platform Strategy & Architecture

• Goal: Provide a web platform for membership organizations with low technical/financial resources (e.g., clubs, nonprofits).
• Architecture: A lean core built on the CRM ecosystem, with functionality delivered via optional, niche-specific "recipes" (e.g., for meetup groups).
• UX Principle: Recipes must be easy for non-developers to activate via a UI, without requiring Composer knowledge.

CRM Core: Relationship Types

• Problem: Determine which relationship types (e.g., "member," "parent") should ship with the core CRM project.
• Decision: CRM core will be lean, providing only essential building blocks.
• Contact Types: Person, Organization, Household.
• Relationship Types: None by default.
• Rationale: This avoids bloat and allows ecosystem modules to define specific relationships, ensuring the CRM project remains a universal foundation.
• "Representative" Relationship: A generic type to allow one contact to act on another's behalf (e.g., parent for child, secretary for CEO).
• Status: Considered a potential generic relationship type for the ecosystem.

Event Registration: Unifying Modules

• Problem: Member Platform needs to register CRM contacts for events, requiring a unified approach across entity_registration, event, and CRM.
• Solution: A collaborative effort to refactor entity_registration and build a new crm_event_registration module.
• entity_registration: John Oltman (maintainer) and Rich Gerdes will collaborate on a new architecture to support non-user entities (i.e., CRM contacts) as registrants.
• event module: Rich Gerdes's module will provide the bundlable event entity type, replacing the simpler event_recipe (which uses nodes).
• crm_event_registration: A new module will bridge entity_registration and event, adding Member Platform's business logic (e.g., access control, guest registration).

CRM Core: Demographic Fields

• Problem: Define a standard set of demographic fields for CRM.
• Decision: Include a set of optional, reusable demographic fields in CRM v1.
• Examples: Gender, , Nationality, Ethnicity, Veteran Status.
• Rationale: Accelerates prototyping and provides a clear path for site builders to add common fields.
• Future Plan: Extract these fields into separate modules or recipes post-v1 to reduce core dependency and allow reuse by other Drupal projects.

CRM Core: Subtypes & Relationships Deep Dive

• Problem: How to handle contact "subtypes" (e.g., volunteer, employee) without creating duplicate records or overly complex contact types.
• Discussion: Explored several approaches:
• Dynamic Field Visibility: Show/hide fields on a single contact record based on a checkbox.
• profile module: Ruled out due to its tight coupling with the User entity.
• Fieldable Relationships: Use relationships to store subtype-specific data (e.g., employment details).
• Problem: The current relationship architecture uses a single contacts field with deltas (0, 1) for Contact A and B. This makes querying and reporting complex.
• Discussion:
• Alternative: Use explicit fields (e.g., employee_id, employer_id) on the relationship entity.
• Trade-off: Explicit fields simplify queries but prevent generic reporting across all relationship types.
• Status: The current delta-based architecture will remain for now, as it is a beta blocker.

Next Steps

• JD: Invite wireframe contributors to Balsamiq.
• Erika & James: Connect to review mock-up notes and collaborate on wireframes.
• Rich & John: Schedule a meeting to define the new architecture for entity_registration.
• Rich: Post the "CRM Events Spec" document to Slack.
• Rich: Post the "Dependent Relations" issue link to Slack.
• Team: Hold the next Slack meeting on Tuesday to avoid the US Thanksgiving holiday.

Action Items

• Schedule wireframe review w/ James re: B's mock-up notes - WATCH (5 secs)
• Schedule architecture session w/ John re: Entity Registration rebuild; then draft plan/new branch - WATCH (5 secs)
• Post CRM Events Spec link in Slack - WATCH (5 secs)
• Integrate Event Registration w/ Event Attendance Group - WATCH (5 secs)
• Post CRM Membership dependent-relationship issue link in Slack - WATCH (5 secs)

Fathom AI Transcript

VIEW RECORDING - 164 mins (No highlights)

@0:08 - Scott Wolpow

Hey, what's up?

@0:10 - JD Leonard (modernbizconsulting.com)

Morning, Scott.

@0:12 - Scott Wolpow

Guess who I'm writing to yesterday? I'm writing to yesterday at a Founders Meetup. Forrest. Forrest Mars.

@0:20 - JD Leonard (modernbizconsulting.com)

Oh, nice. Hi, John. Hi, JD. Thanks for joining us.

@0:26 - John Oltman

Yeah, happy to. Thanks for inviting. Do you go by JD or?

@0:30 - JD Leonard (modernbizconsulting.com)

I do. Okay. I got too many names. Makes things easier. Not always easier. A lot of people see it and they're like, Leonard?

Hey, good evening, Bobbin.

@0:49 - Bhavin Joshi

Good evening. Hi, how are you?

@0:53 - John Oltman

Excellent. how are you?

@0:55 - Bhavin Joshi

Great, thank you.

@1:01 - JD Leonard (modernbizconsulting.com)

So, John, we usually doodle around on here for a couple minutes while people join, and then we'll do proper introductions.

@1:07 - John Oltman

Sure.

@1:14 - JD Leonard (modernbizconsulting.com)

In the meantime, I will repost the link to the meeting notes in the Zoom chat. Everyone can add their info there, please.

@1:37 - Scott Wolpow

Thank you.

@2:01 - JD Leonard (modernbizconsulting.com)

Good morning, Rich.

@2:17 - Scott Wolpow

So, you know, Fars was like an insult that I mentioned the word Drupal Town.

@2:26 - Rich Gerdes

Hey, I think I saw my audio. I'm here at the Drupal Town in New York City, so I'll probably call the camera, but I'll talk to you both.

@2:47 - JD Leonard (modernbizconsulting.com)

I'll give folks one more minute and then we'll pick it off. Okay.

@2:58 - Scott Wolpow

Okay. Alright.-bye. And on next Wednesday's meeting, I'll be away. I'll be at a non-profit symposium for Queens.

@3:17 - JD Leonard (modernbizconsulting.com)

Very exciting.

@3:23 - Scott Wolpow

Morning, Arca.

@3:25 - estevenson

Morning.

@3:27 - Scott Wolpow

I'll be at a place where, uh, McDonough had one of her first jobs when she hit New York City, Terrace on the Park.

She was an elevator operator.

@3:43 - JD Leonard (modernbizconsulting.com)

Morning, Steve.

@3:45 - steven.ayers

Hey, good morning.

@3:48 - JD Leonard (modernbizconsulting.com)

All right, let's, uh, let's kick it off. Let's do some quick introductions, uh, because not everybody has met everybody.

Um, so my name is JD Leonard and, uh, I live in Austin, Texas. This is the Zilker Neighborhood Association's needs inspired the Member Platform Initiative, and I also organized the local Austin Drupal Users Group, both of which are prime candidates for Member Platform.

And I will kick it over to Steve.

@4:22 - steven.ayers

Steve Ayers. I maintain the Open Knowledge Project, and the need for a CRM caused CRM to come into existence.

So how are you doing, Scott? You want to go next?

@4:36 - Scott Wolpow

Sure. I'm Scott Wolpow, based in New York City in Astoria. I helped organize a few of the Drupal cams.

I'd love to see the Drupal New York group get back going. I also have a kayaking and rolling group here in New York City.

And I need CRM for a of projects I'm working on. And I'd love to get away from Civi, which is annoying.

@5:01 - JD Leonard (modernbizconsulting.com)

Fantastic. How about over to Babin?

@5:07 - Bhavin Joshi

Hi, my name is Babin Joshi. I've been helping some non-profit organizations and helping them build members' features and members' platforms seems right for them.

So this is why I'm connected with this initiative.

@5:22 - JD Leonard (modernbizconsulting.com)

Thanks, Babin. Let's go to Erika.

@5:25 - estevenson

Hi, I'm Erika. I'm based inside Toronto. Just trying to think of other interesting details to tell about myself. What have been working on recently?

Oh, kind of like last week. I guess just being discouraged by the job market, which isn't kind of the most productive answer, but it's the honest one.

@5:51 - JD Leonard (modernbizconsulting.com)

Fair enough.

@5:52 - estevenson

And let's go to John.

@5:54 - John Oltman

John Oltman, based in Chicago, and looking forward to maybe meeting some people. And DrupalCon coming up. That'll be my first one, amazingly.

And just working on a few different things and very interested to learn what you guys are up to and more about your initiatives.

Sounds great.

@6:15 - JD Leonard (modernbizconsulting.com)

Fantastic. Thanks for being here. And Rich, if you're able.

@6:20 - Rich Gerdes

Yeah, I'm Rich Gerdes. I'm based in New Jersey, New York area. I'm currently here at the fall school event in New York City, so what's going on?

But I'm the maintainer for the event module, which I think the team's considering, you know, adding to the member platform or CRM ecosystem, but also I've done a number of other member platform sites in the agency world.

So that agency is an association. So I'm very curious how this project's going.

@6:55 - JD Leonard (modernbizconsulting.com)

Fantastic. Thanks for being here, Rich. And James, just in time.

@6:59 - James Shields

Thank How are doing? So, yeah, I'm James from Ireland. I'm interested in member platform for various things I'm involved in, including Lego groups, a cycling group, science fiction conventions.

I'm just getting over nasty flu, so I'm lost my voice a bit.

@7:26 - JD Leonard (modernbizconsulting.com)

Well, we're glad you're with us. So a quick note, next week's Slack meeting, which is usually on Thursday, same time starting as this, is going to be on Tuesday to avoid Thanksgiving Day here in the U.S., and maybe because John, in particular, may be less familiar with member platform and what we're doing here, just a brief overview of kind of what we're doing.

So, anyone, feel free to jump in. Right. Right. Member Platform is a Drupal community initiative to provide what membership organizations need from a web platform.

So very high level, right? That's managing their members, eventually processing dues payments, doing event registration, which is perhaps your interest, you know, integrating into the platform, doing, you know, fundraising, sending communications out to members.

Et cetera, et cetera, right? It kind of will go from there. We've got a particular focus on membership organizations, which you could call a club, an association, a meetup group, a nonprofit that have low technical and financial resources, which leads to some interesting conversations.

And, yeah, we're, one of the big things that we did is we decided to adopt CRM as, you know, a core key dependency.

let's see. I should say, for Member Platform. so Member Platform doesn't have any code specific to it yet, but we have been contributing to CRM and, you we look forward to contributing to other projects as well.

And I think kind of the goal is to be as Drupal-y as possible, as Drupal-friendly and community-oriented as possible.

So, you know, personally, I don't really care what gets put in Member Platform versus some other project, right, that we leverage.

It's really about finding the best place for that so that we are benefiting as many people and projects as possible, whether that's in the CRM namespace, the Member Platform namespace, or elsewhere.

And welcome, Luke. Do you want to do a quick introduction for yourself?

@9:53 - Luke McCormick

Sure, why not? Hey, I am Luke McCormick. I'm Excel here on various things.

@10:06 - JD Leonard (modernbizconsulting.com)

I'm coming in and out of the project to serve a product advisor in various ways.

@10:09 - Luke McCormick

Just got back from Mexico last night, so, you know, catch me up.

@10:13 - JD Leonard (modernbizconsulting.com)

Nice. Well, welcome back. Did we miss that? you've been coming in and out, cutting in and out. So before we get into our agenda, John, did you have any questions off the bat or anything that you're, curious about?

@10:31 - John Oltman

Well, yeah, I have a lot of questions, but I'll try to keep just one here so you can get moving.

Do you anticipate, what is the end goal of your initiative? Is it a recipe or, you know, where do you see this going?

@10:46 - JD Leonard (modernbizconsulting.com)

Good question. I second that question. I don't know that we have determined that exactly. However, I think it is likely that there will be...

be... don't know... ... Uh. A variety of recipes that build on a variety of modules that provide a sort of more niche, you know, out-of-the-box experiences for different types of organizations.

So there might be one for a meetup group. There might be another one for a neighborhood association.

@11:21 - John Oltman

Yeah. There might be another one for something else. That sounds great.

@11:24 - JD Leonard (modernbizconsulting.com)

All built on top of something called member platform, which will lean heavily, heavily on things in the CRM ecosystem and more.

So exactly where those lines are drawn, sort of TBD. And I think what we're more focused on right now is identifying, well, what are the requirements for this platform overall, right, before we get to the specifics for those sort of niche areas?

And I don't even know if those niche areas are necessarily would be called member platform, but they would use member platform.

would custom. So anyone should feel free to jump in with their own opinions.

@12:08 - Scott Wolpow

So have a question. And let's say we put in a member platform. I'm looking at a system. It be good to say, okay, you're running a school organization.

You're running a neighborhood watch or whatever groups you are. I don't like using recipes because that's actually a different thing.

I don't want call like, you know, like copying sort of fixings or mixings. And an easy way to activate them without having the user to know how to use Composer or anything else.

Because once you do that, that means whoever's administrating it now has to go to the Drupal developer to ask them to go do that if they know how to do that.

And frankly, I'd rather not give Composer access to most of my clients because they have no idea what they're doing in the first place.

@12:53 - JD Leonard (modernbizconsulting.com)

So recipes would not be required for anybody to use them, right? There would be an option for customers. You know, member platform in some way.

You could, you know, leverage CRM or other member platform dependencies without any requirement to use recipes.

@13:11 - Scott Wolpow

So how would you not, let's say, a set of fields, let's say, you use one for like the Drupal meetup or for, let's say, your meetup, your neighbor group, how would they activate those?

I'm asking, General, what other people think the best way of doing that? Without having in the core group when you begin.

So sort of like imagine you go to one of the restaurants, and as you pull your tray down, and then make your taco or your empanada or whatever they're making, not empanada, whatever they're making the food, and they throw more things into your plate.

As you go down, give them a this, little of this, how do we replicate that in a good way so that they use...

UX is good also.

@14:03 - JD Leonard (modernbizconsulting.com)

Anybody?

@14:05 - Rich Gerdes

I think my understanding of recipes is that, yes, recipes can be provided in source code, but also that there's supposed to be a recipe browser, so recipes would not need to be part of the source code, right?

So our modules might provide recipes, but you have to talk about might provide a set of recipes for the different ecosystems and different field sets, but they wouldn't necessarily be something that you would need a Drupal developer to go download and install.

I'm not entirely sure how the statistics are that, but I know that the idea with Drupal CMS is that you can, it does ship the recipes, but I think the idea is that recipes would be provided inside of that, and you wouldn't need necessarily a developer to go run address command.

To start a recipe, but I think that's the end goal. It may not be in that state right now, but I think that is the end goal when it comes to recipes.

I don't think we want to necessarily build our own config sets. You know, I think we would want to push recipients to get to a state like that.

Seems silly to rebuild the deal, but yeah, I do. I mean, I definitely would agree that when it comes to a small project, that you don't want to require developer technical knowledge.

It's definitely a little bit too much for a lot of organizations.

@15:23 - JD Leonard (modernbizconsulting.com)

Does that answer your question, Scott? Oh, you're muted.

@15:32 - Scott Wolpow

Yes, to some extent.

@15:34 - JD Leonard (modernbizconsulting.com)

I'll take it. All right, let's dive into our agenda. We, I saw a little progress on wireframes, James. you want to speak to that at all?

@15:48 - James Shields

I've started dabbling with, now I've forgotten the tool name. Thank you. you. Thank you. So I've been working on one of these versions as a, yeah, thank you.

SCREEN SHARING: Jd started screen sharing - WATCH

So I'm just trying to muck that out with it. So I'm just going to try and copy some of the others.

So it's pretty much a work in progress and just figuring out the two, but it's got some fun stuff to play with.

So hopefully that's it. But I suppose we can start with B's mock-ups and then maybe we can see what, you know, what bits of them we want to keep and what bits we want to, whether we want to drop some of it or simplify them or maybe sort of bring back some of them in later releases.

We can discuss that and hopefully other people can chip in. And collaborate on those designs. Sounds good.

@17:06 - JD Leonard (modernbizconsulting.com)

Thanks, James. Yeah, James is kind of taking over the reins from B, who we haven't heard from in quite a while, unfortunately.

ACTION ITEM: Schedule wireframe review w/ James re: B's mock-up notes - WATCH

And we're fortunate to have a year-long trial of Balsamiq through their Do-Gooder program, which has unlimited users. So if anybody else wants to contribute to the wireframes and editing, just shoot me your email address and we can get you invited to that.

And I wonder, Erica and James, if I could volunteer you two to maybe connect at a time of your convenience to try to work through, you know, maybe some of those mock-up notes, Erica, that we had been kind of focused on in preparing for B, just to give James a little more context, maybe, for, you know, whipping up these mock-ups.

@17:54 - estevenson

Um, sure, I'd be willing to kind of what, um... ... ... ... James, we message each other, like, after this meeting to just figure out a time to go over it?

I'll do my best to assist. Absolutely.

@18:09 - JD Leonard (modernbizconsulting.com)

Fantastic. Thanks, y'all. All right. Next on the agenda, what relationship types should CRM provide out of the box versus in separate modules in the project or in different projects?

And I think the question is actually not so much first, which relationship types, but is more where should relationship types live, right?

Where should they be when you install CRM or some other module? So we had some discussion on our Slack meeting last week, and I thought it was worth continuing that discussion today.

So anybody with thoughts?

@18:49 - estevenson

I mean, are we just talking about version one, or are we talking about kind of more foundationally?

@19:00 - JD Leonard (modernbizconsulting.com)

I think foundationally, probably, because I think it's about, like, does the CRM project itself, which currently includes some relationships out of the box, is that the right place for them, given the model that some other projects have taken, like Commerce, where Commerce Core has basically no content entities, right, that are shipping out of the box.

But there are ways to add those in later, right, whether manually or through recipes or installation profiles, etc.

@19:41 - estevenson

So I guess sort of my starting point would be kind of what is pretty much, like for version one, the answer is easy, and you just don't worry about it.

But, you know, kind of then what would the timeline be, and what would the milestones be, like, as a project?

We want to kind of definitely sort of commit that for version two, we want people to be able to register on behalf of other people, in which case, just given the sort of general use case, I might limit that to households, just because like, in terms of the meetup kind of like use case, like there isn't a significant difference between a household and an organization, you know, kind of, unless they're sort of like, and I would just, if you were dealing with like volunteer, then that might be its own sort of module.

I'm not sure, though, I feel a little bit unqualified.

@20:37 - JD Leonard (modernbizconsulting.com)

So I should, I should probably take off the member platform hat for a moment, put on the CRM hat and say, going number platforms requirements, right?

What should a general purpose set of CRM building blocks provide out of the box? You know, obviously it provides the concept of relationships and, but which, which relationship types, right?

Should it provide? Out of the box? Or should it provide none? And if none, then where do the ones that exist currently, where should they live?

So that they can be relied upon by ecosystem models.

@21:08 - estevenson

Okay, so this is less about member platform and more about kind of, like member platform is an example of where we think about it, but this is more kind of CRM kind of foundationally, should it be plucking out its bits?

@21:24 - Bhavin Joshi

Well, in my opinion, we are offering something good out of the box and flexible, I believe we allow the users to define the relationship as well.

@21:37 - JD Leonard (modernbizconsulting.com)

So, Bhavan, can you clarify, you're saying that you believe the relationship type should ship as part of the CRM-based project?

@21:46 - Bhavin Joshi

Yes, indeed, because with CRM, user would be able to define the relationship if there is a flexible option and it is not too tight with the module and a hard-coded relationship type.

But it is always good to provide with the option that user can define relationship based on the requirements.

@22:09 - Scott Wolpow

So, you I think that we should provide that the citation, the real basic, most basic information, first name, last name, organization name, and means of contacts.

Then each user can provide a relationship based on what they want to do. Because there are way too many for us to ever provide one.

And if provide one that's preconceived, people get stuck and frustrated. And I would love to make it a nice goob and say, okay, you have this person or this group, and these are the things, by some means, that can control these contacts.

And where you create your own contents, and okay, I give permission to my assistant to change my contacts. And I give permission to the people upstream, or the upstream people say, you're...

have no choice when I create your contact, I control it. But just in this call, there's so many different permutations of the relationships.

So we need a way to make it universal, uncomplicated, and unneeded, although somebody wants it.

@23:19 - Rich Gerdes

I think to Scott's point, my take on this would be that the most basic concepts are individuals, right? People and groups of people, right?

So organizations of some sort. And those are the two types of contacts that I would think the CRM would provide out of the box.

If you want to talk about businesses or nonprofits or all that stuff, you would create, you could create or clone the concept of an organization.

And the same thing, if you want to have different types of people, parents, children, volunteers, you would clone the concept of a person or an individual.

And I would think that you would want to be able to relate organizations to people. And that would be the one.

Thank you. Thank Default, like, member relationship type that might come with CRMs. And then, yeah, if we want to provide some templates for, you know, a homeowner's association or, you know, school or something, those would be either recipes or another module that provides that conflict set on top of the basic concept of, you know, individualization.

That would be the way that I would probably structure it.

@24:25 - JD Leonard (modernbizconsulting.com)

And so, Rich, I think we've kind of landed on person, organization, and household would be the contact types that ship with CRM.

But the question is more about, given that, right, what relationship types ship? And I heard you mention member and maybe no others.

@24:43 - Rich Gerdes

Is that what heard?

@24:44 - JD Leonard (modernbizconsulting.com)

Yeah.

@24:44 - Rich Gerdes

So, yeah, I think to your point, right, if you're doing families as a third one, right, you would have, you know, family, right, and then you would have, you know, for both of the family and organization, I would think that would be the extent.

I think that your agenda item includes head of household. think, you know, designating an owner or manager of an organization.

But I think they could come across as different names, right? If you're at a household, is it parents? Is it, you know, how many levels are you providing?

You may just want to, I think we had the concept of like a default relationship. And so instead of having head of household, just have members in one as a default.

@25:31 - JD Leonard (modernbizconsulting.com)

Your voice was cutting in and out there, Rich. I'm not sure if I completely followed that, but did somebody else?

@25:36 - estevenson

Um, I know kind of, if I am, to me, what would be nice about being able to take kind of some relationships in and out is that then kind of, don't have to ignore kind of things.

That I think for member platform, what would, what might be nice instead of kind of family would be to have a representative kind of relationship to a different con.

Without necessarily belonging to it, because inside general, kind of like that's what people want, that the CEO kind of wants his secretary to be his representative, but mom wants to be the representative of her kids.

So that is the most generic and simple. And kind of, I know, like, I think household is good enough, you know, kind of like functionally, but, you know, kind of, it is sort of prescribing a certain way of thinking that, yeah.

So I would be tempted to do organization and representative, because, yeah, in terms of member platform, you don't really need to know a family, which is just sort of, yeah, that I know inside my thinking, I was thinking of the head of household as a version of representative and just sort of a way of using the existing model.

But do we actually need anything more specific than representative? I don't know if that makes sense.

@27:02 - JD Leonard (modernbizconsulting.com)

And so just to add some clarity for anybody who hasn't played around with it yet, so the relationship types that are there can be deleted, right?

Can be renamed, can be ignored, and can be added to. So we're just talking about defaults, you know, not what is supported.

And I think part of the point of having some, you know, defaults out of the box from something is so that the rest of the ecosystem can rely on that.

So if somebody wants to create a family tree module, right, that can rely on the existence of certain familial relationships, right?

Well, maybe another module could also rely on those familial relationships, right, to do something else. But they can only do that if they maybe agree, right, on what that relationship is.

Or have some sort of complex, you know, abstraction to let somebody configure select this relationship sort of represents this.

I wonder, go ahead, Erica.

@28:03 - estevenson

No, I would agree that kind of family as a generic makes sense to me that just having that by default.

Yeah, so organization and family. I'm just trying to think if there's anything that doesn't cover. I would be very tempted to just have representative.

You know, I sort of worry that's just sort of dodging the issue, because if you have the generic, everyone's going to use the generic for things that, you know, you probably should define something more proper for.

@28:37 - JD Leonard (modernbizconsulting.com)

Steve, I feel like we're here for you.

@28:39 - Rich Gerdes

Yeah, I just want to go ahead, Rich. The representative would be a relationship between individuals. Is that your thought, Erica?

Or would that be between families and groups?

@28:55 - estevenson

I know what, so people belong to a family. And then have relationships to that family. But yeah, no, I might be kind of like, I am unsure about this, but pretty much, you know, kind of one thing that is similar, kind of, I am a mom, I want to be a representative of my kids.

Or I am kind of, you know, sort of the secretary of X, I want to be the representative of X.

That is sort of a generic that almost doesn't need kind of like an associated group. Like maybe that's sort of like fundamental to how kind of the DRM is supposed to work.

But yeah, kind of like functionally having a generic that this person can act on my behalf without having to specify a specific group is sort of a generic case that I could see being useful.

Um, but maybe that sort It goes against the logic of CRM, but I know kind of like when I was going through and testing it, that was one thing that popped into my head, is that it's sort of, yeah, that that is something that different roles are trying to arguably be.

Like, I don't know if you can say head of household is trying to be anything, because nothing's sort of using it yet.

But, yeah, that, or possibly it is a quality that could be applied to sort of roles. I don't know.

@30:36 - JD Leonard (modernbizconsulting.com)

Let's go to Steve. The concept is clear.

@30:39 - steven.ayers

When you're talking about representative or something acting on their behalf, are you talking about like some sort of permission system then?

Like where that user linked to that contact could then, by that relationship, view, edit, or potentially...

@30:56 - estevenson

Theoretically, or you could just have that, you know...

@31:00 - steven.ayers

Is it more of the site, the person using the CRM should know that if they need to, like, right, this person's a minor, so their guardian or contact person is this, like, right?

@31:16 - estevenson

Pretty much, that you could have kind of, like, a system that this is, yeah, like, without necessarily attaching any behavior, if you wanted it purely kind of visible, that this is sort of my lawyer, he represents me, kind of like if I am looking this up, I sort of know that, you know, sort of, this is sort of my mom, she represents me, or kind of alternatively, I represent her, that that is kind of...

@31:42 - steven.ayers

that's like a power of attorney status, then.

@31:44 - estevenson

Mm-hmm. But, you know, kind of, so that is, there are many things that seem like they affect, like, functionally, you know, for a member platform, I mean, the relationships we care about are the ones where someone can act as a representative.

So this arguably, it either is a relationship or it is possibly kind of a quality that gets added to relationships that, you know, kind of this relationship entitles this person to some permissions over that person, even if kind of the thing that enforces those permissions is entirely offline.

But, yeah, kind of that was one case where, yeah, that, you know, kind of head of household kind of maybe logically implies that you have some, you know, kind of ability to represent others, but maybe you don't.

Maybe kind of like it's meant to do something else. And, yeah.

@32:51 - steven.ayers

So there's a backlog item to allow relationships to grant permissions to view, edit, or delete, you And which way do they go?

@33:02 - estevenson

So head of household would come with more default permissions than just a household member.

@33:07 - steven.ayers

Part of having default isn't necessarily just to provide things that will cover every use case, but a good way of demonstrating what the features are out of the box.

So just hypothetical, if we wanted to demonstrate being able to limit the number of relationships, like, right, most people only have two parents.

@33:28 - estevenson

That's a good idea.

@33:29 - steven.ayers

we change that, but by having defaults, we can then show some of those features.

@33:34 - estevenson

Now I'm immediately thinking of kind of guardians and step parents.

@33:40 - Scott Wolpow

That's one type of unit, but let's say, for instance, they built one many years ago on a different platform for chain stores.

So they have the chain, the very top of corporation, they can add, change logos and other things. And as you get down to the store level, the store manager.

I'd be able to add an extra coupon locally, change the hours, and so forth. So maybe that's not so much in the CRM as that in profiling, but the CRM could populate a profile.

Is that separate? So how do you put all that together to say that, okay, the downstream, you that's very top of the heap control everything below you, and then you get to each level, you can control what's below you.

@34:31 - estevenson

But there's cases where kind of you actually want it to go from bottom up.

@34:37 - Scott Wolpow

Right, that's a separation. That's where you have a person working somewhere that has the ability to make some other changes for their immediate superiors where they're assigned.

So we need to have an ACL that works in both directions based on the use case.

@34:57 - estevenson

So I want to be careful to not go too far.

@35:00 - JD Leonard (modernbizconsulting.com)

We're down a rabbit hole here because now we're dealing with access permissions related to relationships, but we haven't really answered the core question of should relationship types ship with the main CRM project or should they exist somewhere else?

@35:20 - Scott Wolpow

No, they should exist somewhere else, but the CRM should be to have a hook into doing that. Should be ready to handle that when needed.

@35:30 - Rich Gerdes

Yeah, I mean, my take on this is if we're providing three different content types, I think we would want to provide corresponding relationships, and that sounds like a person-to-person relationship, so representation, whether that's secretary, boss, you know, child, whatever, just a person-to-person, you know, represented by or related to concept, and then if we have families and organizations, the concept of a member of that family.

@36:14 - estevenson

So, I mean, it sounds like what we, just because people can build their own kind of relationship types, that what we want is different examples of the Lego blocks and kind of like certain shared concepts.

So that you can have kind of both this and this module build off of the concept of household, because there is a shared rules that we've defined, and that's going to be the default.

So kind of household as, you know, kind of like demonstrating to primary parents, just because that describes, oh, you know, kind of the concept of limiting the number is sort of like.

Yeah, I would agree that makes sense. And so like, is that logically what we're trying to think of is examples where a shared understanding is useful and examples where we're showing off the Lego blocks?

Does that make sense?

@37:15 - JD Leonard (modernbizconsulting.com)

Let me ask you a different question. Do these examples belong in the CRM project or in a CRM examples project or in a CRM family relationship types project or, you know, something like that?

Where do we draw the line? What should the policy be?

@37:33 - Scott Wolpow

I think the CRM should be as simple as possible and that you have CRM add-ons, be a member platform, company platform, chain store platform, whatever you want to call it.

The CRM should be as simple as possible so people can get in and build what they need. Use the Lego example.

Rather than having a predefined house, you're the basic building blocks. To start building what you need in Lego, you have a little base, and instead of six pieces, or two by threes, or two by fours, and all that, the real basic pieces to start out with, you know, you can't give them the Eiffel Tower to build in a basic set.

@38:22 - JD Leonard (modernbizconsulting.com)

So, I think we should probably move on for time. Steve, any final thoughts, particularly given that you are the source of the current relationship types in CRM?

@38:32 - steven.ayers

I don't have enough experience or knowledge to make an opinion or decision call at this point. I will be in a much better position to comment on it after working out more of the details of CRM membership, right?

That's using the member relationship, and so that will give me a better idea of where things belong. I would comment, though, that this is the CRM project.

Not the CRM Core Project. Steve, they don't get your reference. Yeah, they don't, do they?

@39:10 - Scott Wolpow

Are we talking about the CRM project that's called CRM or are talking about something else?

@39:17 - JD Leonard (modernbizconsulting.com)

That's what I'm saying.

@39:18 - steven.ayers

We're talking about CRM, not CRM Core. Steve, nobody thought they were talking about CRM Core. You just confused half the audience.

Hi, JD.

@39:27 - Rich Gerdes

Steve, context there. How does CRM and CRM Core relate? Does one depend on the other?

@39:34 - steven.ayers

BFL of CRM and a maintainer of CRM Core, and the only organization that uses Drupal 8 CRM Core is some company I used to work at.

@39:45 - Rich Gerdes

And does CRM Core extend CRM?

@39:50 - steven.ayers

No. It's no unrelated.

@39:52 - Rich Gerdes

Different architectural designs.

@39:53 - steven.ayers

Okay.

@39:55 - Rich Gerdes

Just clearing that up. Yep.

@39:58 - steven.ayers

Very good.

@39:59 - JD Leonard (modernbizconsulting.com)

So we'll... We'll have some more discussions around relationship types and how they relate, given how the sort of ecosystem is developing and the vision for that ecosystem is developing.

But thanks, everyone, for your thoughts on that today. So let's move on to entity registration and member platform, CRM, and event, and event registration, et cetera, et cetera.

I want to thank John for joining us today. He's the maintainer of the entity registration module. And I want to thank Rich for joining us and for diving in and, you know, taking a first stab at how could we, I guess, add to entity registration so that it can support non-users as registrants, i.e.

contacts. So, Rich, John, you want to take us away at all?

@40:56 - John Oltman

Yeah, Rich, do you want to start or do you want me to comment? Sure. Good.

@41:00 - Rich Gerdes

Yeah, I can start with first a high level, which is, for your context, the main difference in between the registration module and my event registration module is that the registration module lets you register a user or an anonymous user for anything, and my event registration module lets you register basically any entity for specifically an event.

@41:29 - John Oltman

Yeah, so I looked at what your merge request, and yeah, I mean, you got a lot of, there's a lot in there.

It's pretty amazing how far you got. But I have some ideas about, you know, trying to, I think this could be an opportunity to improve the overall architecture of the module.

So, my. Our thought is to, you know, continue to assess it. Maybe we can work on architecture together, but I definitely have some specific thoughts about how to work this in, and I agree.

I think it's a new branch, I think, but I think it can, I think that I love the idea, and I think that this can lead to better things for the module, in short.

@42:24 - JD Leonard (modernbizconsulting.com)

Fantastic. Thank you for your support, John. And, you know, for sort of more context, right? So member platform has a need to facilitate event registration, and because we depend on CRM, and contacts is sort of our world, right?

The contacts need to be the ones registering for events. And, you know, we want to leverage the best, you know, in the Drupal ecosystem, and entity registration ticks so, so many boxes.

And also, you know, looking at some of the projects that Rich maintains and seeing that, you know, there is a place where a sort of generic event, you know, entity type could live, and it would be great to be able to standardize around, well, what do all events have, right?

Or at least what should all events optionally support, right? Whether for member platform or other, you know, use cases, so that we can build an ecosystem around event, an ecosystem around CRM, and, you know, an ecosystem around events in CRM, right?

And just try to have it all be additive, and have everybody working together instead of, you know, having kind of divergent approaches to doing things and having kind of custom, you know, content types or brandy types to do it in each project.

I think that's a great need and a great direction.

@43:58 - John Oltman

One question that comes to mind. I know that there's event recipe, and I know that we don't want to rely on recipes, but it'd be interesting.

Do you anticipate trying to leverage events in that, or where do you see this going in relation to that?

@44:16 - JD Leonard (modernbizconsulting.com)

I can come up with an answer, but does anybody else have one?

@44:19 - Rich Gerdes

Well, my understanding is that the event recipe just creates an event content type, like a node type.

@44:26 - John Oltman

Yes. That is fieldable.

@44:27 - Rich Gerdes

So, and my take on that, and why I pick the event module, and why the event module exists, as opposed to just using the content type, is that you have different types of events, which might have different requirements, like registration tiers, or registration types, or tickets, or whatever it might be.

So, one content type for events isn't sufficient. So, that's why I've gotten the event entity approach. you may have event type, you you may have a conference.

may event type, type, type, you you may type, Recipe that sets up different event types or something, but I think that's, you know, a discussion for the future.

@45:05 - John Oltman

Yeah. Okay. So the event, because I'm not that familiar with your module, but the event, it's a custom entity type, and it's sort of like a super entity type.

In other words, it's not just a content type.

@45:17 - Rich Gerdes

It's got all, it's event aware, effect. Yes. It's an entity type, and then it can have its own bundles, right?

So it can have its own content types underneath it or event types underneath it.

@45:29 - John Oltman

Yeah. And then it had, but out of the box, it's event aware, unlike an event content type doesn't have any awareness.

It's just a content type that happens to be named event. Yeah.

@45:39 - Rich Gerdes

And events have dates and other stuff with them.

@45:44 - Scott Wolpow

So we kind of mean, back in the days when we did Joomla, and they, of course, isolated all the content types into different channels.

And I don't know if it ever changed, but we have what they call plug-ins, so you can cross over.

So not every event needs. needs. The CRM attached to it, but if we're an organization, you want the CRM there to record who's attending events, what's going on, and then be able to go into the event and have the permissions to make changes to RSVPs.

Does that really come under the event rules and the event type things rather than CRM? The CRM should just have conduits to information about that contact, be it sales, attendants, or anything else.

So, I mean, the CRM doesn't really care about the event. It's just another function that it records. For instance, what I'm building is I want to know if someone's going to claim their profile.

So, the profile is being powered by the CRM, but when I look at it from the CRM standpoint, I just want to see if they go claim their profile, that's all I really care about, so I can monitor and have the relationship with the contact, that's what CRM really is for.

Or if you have e-commerce, the C becomes customer, but it's still really the same thing.

@47:08 - JD Leonard (modernbizconsulting.com)

Yeah, and we'll see, Scott, right, as the ecosystem develops, right, kind of where the appropriate places to plug all those things together are, right?

And so I'm hopeful that, you know, if we can move event in a direction that's sufficiently generic and entity registration to be sufficiently generic for our needs, right?

You know, now we build this sort of pyramid of modules that depend on one another, and then they're logical places to add, you know, whatever specific requirements you might have in the appropriate place.

John, to your question about the events recipe, like, what are we doing there? So, I mean, I've had plenty of discussions with Martin, who I think, you know, is kind of the maintainer of that recipe.

@47:57 - John Oltman

Yeah.

@47:58 - JD Leonard (modernbizconsulting.com)

And while we haven't specified. Specifically talked about sort of what the future is there. As it relates to the recipe, I think the recipe is very much incompatible with sort of what we're doing right now.

But maybe a future version of that recipe could leverage, right, an event, an event content type provider, entity type provided by an event module.

@48:23 - John Oltman

That's what I think. Because, I mean, really providing a content type is just not that much. So I think the rest, if the event module can get to a certain place, in my mind, I think it would be wonderful if that recipe could leverage something that's way more event aware rather than just creating a content type.

@48:45 - JD Leonard (modernbizconsulting.com)

Agreed. Rich, any thoughts as the event maintainer?

@48:50 - Rich Gerdes

I mean, yeah, I think that's, you know, my objective is, you know, we have a content management system that does type data.

You know, we should have a structure of concepts and not just nodes. They're very generic, but, you know, code can be written to handle that if that's, you know, the route.

But I think as far as, you know, the current need, it's deciding, you know, I think the solution is basically to figure out, you know, the best solution for managing registrations, which I think is consolidating to a single module that does that.

And then, yeah, we can figure out the kind of structures we might have down the road. So, but yeah, I think for the moment when it comes to that is just, yeah, I think we have to talk through, you know, what, what exactly the requirements for future registration and how best to implement that module architecture, data architecture.

ACTION ITEM: Schedule architecture session w/ John re: Entity Registration rebuild; then draft plan/new branch - WATCH

And yeah, I think I want to have a separate discussion to dig into that.

@49:44 - John Oltman

think so. Because I like, like you made some comments about moving the anonymous email out of the registration entity type.

And that makes total sense to me. I have some, I don't want to have a dependency on profile, but I have some ideas that I think would, that, you know, you would like.

So yeah, definitely let's collaborate. But yeah. I want to support your initiative in any way that I can, and it sounds great.

@50:06 - JD Leonard (modernbizconsulting.com)

Fantastic. Well, thank you all so much. Let's, for time, move on to default values for CRM demographic fields.

@50:12 - steven.ayers

Steve. So, right, the question to be asking us is, if we were to include demographics, what should the defaults be?

SCREEN SHARING: Steven.ayers started screen sharing - WATCH

We haven't made a decision on what demographic fields to include, and that conversation isn't today. So, where we can, I'd like to find some sort of existing standard to reference.

So, right, I was able to find this standard for dealing with international data together with censuses. If you take a brief look at this, you'll notice that it only has male and female.

This one, which is developed by a health insurance company, I believe, in the United States, does include Intersex as well.

time. go. So, So, let's go. Although one of the downsides of this format is that it's using letters, which is kind of reliant on the English language, whereas using the ISO intentionally chose to use numbers to avoid any sort of favoritism towards a language.

And then this is what was also included in the standards. right, one is male, two is female. That's just the most popular system in the world at the time.

So, that's what they adopted. So, right, here's a PDF of that standard if you really want to read it.

Oh, I want to, yeah, there you go. If I get charged with copyright or piracy, I feel like it's going to be for ISO standards.

Insert laughter here. All right. So, does this really mean? Okay, so this is a tugboat instance, this merge request.

let's do Right. This no changes have been made. I've only navigated to this page. So for all the demographics we're talking about, by including them, what we mean is that if you click here to reusable fields, there will be a field here called or whatever the demographic happens to be.

Right. And then. You can change all the values you want. Right. And one of the things I was thinking is we would not only include help text maybe, but under here where it has help text, we might include a help topic to, you know, sort of more information about whatever standard designated the defaults, or if there's a competing standard, we might include both, but that's just sort of my thoughts.

@52:51 - JD Leonard (modernbizconsulting.com)

I've got a question, Steve. You mentioned, you know, explicitly, right? You can change any of these values.

@52:58 - steven.ayers

Yep.

@53:00 - JD Leonard (modernbizconsulting.com)

That would, of course, cause it to deviate from the standard. Is there value in having, I guess, a version of this where you can't change, you can't deviate from the standard so that any other modules that want to rely on the existence of this and the standard values can safely do so?

@53:22 - steven.ayers

Uh, probably not. I mean, there might be some value in allowing a module to detect that and then, I don't know, give a warning or even perhaps a revert to defaults.

But I'm pretty much like the let the user shoot themselves in the foot, just, you know, give them a warning message.

If you really want to pull that trigger, you will put a bullet in your foot. Do you want to do this?

Yes, no. So, so that's my sort of philosophy on letting users change values. Um. I mean, I could see there being value in having maybe an intersex, but if we're going to be, like just talking statistically here, it's a very small percentage of the population.

So unless you're dealing with medical records, but yeah, that's a standard. You'll notice that there are other demographic fields.

I don't really want to spend the time to review them here today just because one time and two, there is no pressing issue on this.

This isn't a beta blocker. This is just, let's have a conversation about demographics. So it's the same idea with any of these other demographics.

Nothing's going to be added by default. The site builder has to add and review the available options. And we had a discussion also about nationality and, you know, the site builder as well could then choose.

I mean, let's save these settings. Oh, it was right there all along. My bad. let's mean, mean, save this.

Right here, right, if you wanted to change it for nationality to have more than one, right, the site builder has that ability.

doesn't really make sense, right, to be a multi-value.

@55:15 - JD Leonard (modernbizconsulting.com)

Who's got thoughts?

@55:19 - estevenson

Oh, having kind of, inside my last job, viewed sort of several different ATSs that involved kind of jobs and people applying.

Having a field called, like, prefer not to say or not specified was really, really, really common. Like, I don't know if I ever saw it.

It seems to be something people request a lot, you know, kind of that, you know, kind of prefer not to say or just sort of something like that, which isn't part of the standard.

But, yeah, on a practical level, that seemed really common and is clearer than not applicable because kind of, like, people can just...

you very much. Alright. Thank Okay. I don't want to say my . Not applicable is more of like an administrative code for, I mean, I wouldn't recommend adding the field to an organization, but if one were to do that, not applicable is the value that should be selected.

I would think. Yeah, so I guess functionally it came up a whole lot and sort of different than not applicable.

@56:26 - Scott Wolpow

I just think your point, Erica, is that we should be inclusive, right?

@56:33 - Rich Gerdes

So, you know, we shouldn't be excluding people who don't want to provide that information, right? And unknown is I don't know versus they didn't want me to know.

@56:44 - Scott Wolpow

I think we should just be leaving most of organization. Prefer not to say I think it's fine because that's really not a big deal.

It covers a lot of different subjects. But anyway, the least amount with a little atom, please feel free. Free to add whatever information you want, all the choices, so they know they can do it.

That way we don't run foul of anyone who might be offended on either end of the offense spectrum in this area.

@57:14 - estevenson

Well, on the offense spectrum, I just make sure to include and gender. That, you know, kind of does tie back to kind of a, like, medically, what are you?

You know, kind of like, and that can be prefer not to say. Again, people would have that option. And just, I just know, kind of like, based on different trans friends I know, that they tend to be kind of satisfied with kind of having both gender and .

And those are two different things. And so long as there is the option that, yeah, I don't really want to say, but here is my gender.

Yeah, from what I can tell, that's generally the sort of... ... ... Dividing point to deal with the fact that, yes, kind of there is physical existence, and then there is kind of what you identify as, and those are two different things.

I guess the question that really is at hand here is less about what individual demographic options should exist, but should we provide demographics, and should they be enabled by default as fields, or is that something that should be provided as recipes or separate modules, right?

I don't know if we're really trying to answer the question of whether or not this should be included or not today.

I know it's a little backwards, because, right, you would usually maybe think of that first instead of thinking about what the defaults are, but there's a lot of demographics, and I think if we have a good idea of what the defaults might be, that might help us answer the question of whether it should be included or not.

I I think it would make sense. It's to include it because it's relatively minor. Like, mean, kind of like on a technical level, kind of, yeah, that it's easy enough to remove.

And it is something that comes up a whole lot inside client relationship management. That, yeah, kind of relationship management.

Yeah, you do keep track of qualities. And even just sort of suggesting that to the user, particularly because we're dealing with kind of low technical people, or at least that is just sort of like a goal.

I don't know. My sort of gut is to include it because it just seems like a lot of work to not include it.

And little harm if it is. Well, yeah, flip side of that is it's also work to maintain a list of nationalities in the long term, right?

I mean, we're not talking about ethnicity. We're talking about nationality, which doesn't equal that ethnicity, nor should it. Necessarily correspond to your location of birth.

We're talking about citizenship. Yeah, but maintaining a list of countries that is accurate, they change regularly, right? You know, they change their preferred spelling and stuff.

Well, JD and I had a conversation about Myanmar and Persia. I will accept that Iran and Myanmar exist as places and will not insist on referring to them as Persia or Burma.

Though, we have drinks, I might refer to them that way in private. My point is that when someone... does maintain a list, though, of countries, so...

Yeah, well, the hard part is, yeah, if we are providing that as config in the Drupal module, we have to update that config every time that changes.

In theory, there's libraries, you know, Commerce does that with an address module that knows the schema of an address, and that's how CommerceGuys handles the changes to addresses of one library.

So, just a data point there. Or is that, do we want to maintain a list of demographics, you know, nationalities, you know, and gender maybe, but how far do we really want to go there with maintaining that information, or is there ways that we can supply that from somewhere else?

So quick note, we have reached the official end of our meeting, but as usual, I'm going to keep this Zoom going, and we can continue this conversation and then transition into a working session on requirements on a topic to be determined.

So I'll just say thank you, everyone, for coming. Feel free to drop off if your schedule doesn't allow or you're not interested in continuing this, and we'll see you all on Zoom again in two weeks or on our Slack meeting on Tuesday.

Thanks. Nice to meet everyone. Thanks, John. I don't think we need to spend too much more time on demographics since there's not like a pressing need for this.

I agree. Just one thing to note on the list. A of countries is DrupalCore does maintain a list of countries that we could potentially piggyback off.

Well, so here's the thing. There's a both. Of course there's a both. Here's the thing. Nationality isn't the same thing as a country.

So, JD is a British national and an American citizen, but he's not in a British Indian territory national, which is a different level of citizenship.

In the United States, if you are born in America, Samoa, you are a U.S. national, not a U.S. citizen.

You can't just move to the mainland from Samoa. You have to get, like, it's not as complicated as immigration, but, like, it's not like Puerto Rico where you can just vote for president if you come to the mainland.

Wow, Steve, they really are second-class citizens. Yes, they really are. Yes, like Alberta. Damn it, Steve, you shouldn't have said that.

So apart from the obvious challenges with, you know, maintaining, you know, that list, which when you're dealing with sort of nationalities associated with a country or territories like can get pretty complex and nitty gritty.

What I'm kind of seeing, right, in the discussion around all these demographic fields is, well, that's a logical grouping of fields, right, these sort of demographic fields.

What other, you know, groupings of fields or fields are sort of commonly used, right, in data that you track about people or organizations, right?

There's a lot of different things that we could include out of the box, right, or include somewhere. How do we determine what that set

I mean, I know kind of functionally, veteran status came up a lot, you know, kind of like a weird amount of times, or maybe not weird.

I found it kind of surprising. A lot of organizations cared about that. Yeah, a lot of grants have, you know, money if you give work to veterans.

It's just, yeah, there's also, there's also federal filing stuff for corporations. If you have people with disabilities, veterans, these are things that you as a corporation, you track because there's tax benefits and legal requirements to report that stat too, if I can do it.

The test to be found out of a box is something that everybody uses. So if you're doing one for a local school, no one cares about veterans or your nationality or any of that.

It's irrelevant. So Scott, what Steve showed, though, he was sharing his screen. Right? Is that it was not attached to the person contacts type, right?

It was just available for a site builder to add. Oh, yeah, yeah. If it doesn't add to it with ease, that's fine.

That's what I was saying before. It should be a real easy method just to turn it on. Say, please add this to my system so they don't have go figure out how to create the fields themselves.

Now, it'd be even nice if you could import a YAML into the system that would go set those fields up for you.

And so, like, high-level strategically, right, it is valuable to provide, it could be argued it's valuable to provide fields out of the box, whether they're attached or not, so that they are, A, easy to add, B, standardized in some form, so that...

You know, CRM ecosystem can be aware of them under a, you know, well-known name, right, and do logical things based on that existing.

But I think there's, it sounds like there's still very much a question of, well, does this belong in the CRM project itself or in some, you know, project that depends on that and that other modules would depend on?

Or even should some of these things kind of be in their own modules and then you sort of pick and choose which modules you want?

Or maybe you apply a recipe that gets you all the demographic fields or, like, there are a lot of different kind of options, right?

And I think it's sort of a complex thing to decide, like, where does this stuff belong? I mean, if we're, if we're creating fields, they're potentially useful to things outside of CRM or member platforms, so.

I think it makes sense for them to be separate projects rather than part of the CRM project so that other things can use them and potentially creates incentive for other people who have no interest in the CRM project to contribute to them.

I mean, a nationality field is an example that springs to mind that there's definitely potential for that to be useful in other places and it's kind of arguably peripheral to CRM.

So kind of making it its own project, I think it, first of all, being useful elsewhere seems, you know, I don't think.

think we should force people to have CRM project to use these things, and also it could potentially give us access to developers or maintainers that mightn't be interested in the CRM project itself.

So it kind of widens our pool of potential resources to work on these parts of the project. So I'd broadly say that as much as possible that doesn't need to be in CRM should be its own project.

We may want to either use recipes or dependencies for bringing them into CRM so that we might want to have a core list.

of field types that will be installed, I suppose, if we make them a composer dependency of CRM, they will be loaded with your CRM project, and it means that you'll still have to enable them in the extensions tab, but they will be downloaded with CRM, so you don't need to go hunting for everything.

I'm kind of, probably, personally, my preference would be more for putting them into a recipe rather than as dependencies on CRM, because if somebody wants to have kind of a lean CRM set up, we might not want to, they might not want that forced on them, but...

And I'm kind of, you know, it's not a hill I'm going to die on, but, you know, it's kind of, I would probably, you know, I'd a slight preference for kind of not including things in the CRM unless CRM actually needs them.

So, James, your proposal for, you know, the fields kind of being in their own modules so that projects other than those using CRM can benefit from them speaks to me pretty strongly.

These are core fields, so you can't use them for anything other than a contact. I'm only including a YAML file for storage.

There's not like, there's no custom code here, people. The only thing custom here is that it's not prefixed with the word field.

Okay. are few demographic fields involving height and potentially gender that might rely on a different field type, in which case, right, you'd have to have that module installed.

So, like, the question of whether or not they should be included, right, was not, is a bit more complicated for some of them.

So that's one of the reasons I was trying to avoid that discussion today. Nice try. Yeah. Yeah. I think my take on this is that we're building version one, right?

Let's just include them, right? We're building version one. Let's prototype what these would look like, and we can see if they're valuable and optionally move them to recipes once recipes is figured out.

No, none of us know how to write recipes at the moment. We're not writing recipes. We have no other recipes at the moment.

Let's just include them for now, and we can move them out later with version two, right? That makes sense.

To me that, you know, kind of at some point it might make sense to sort of move them. But right now it's kind of premature optimization that we can kind of like throw the spaghetti at the wall and then kind of figure out what goes inside a side dish.

I guess one challenge includes. They call it gender, but your options are female, male and other. I know in the past they had male, female and transsexual for , or I don't know, they at some point changed it to gender as a label, but it's a field, not a gender field, right?

Well, mean, kind of like it captures instances where sort of, yeah, sometimes you medically need to know kind of like what's inside people's pants.

And, you know, kind of like, and people like to distinguish that, you know, kind of what is inside their pants isn't necessarily what they identify as.

So it's good to have both. People like having both. So as far as a set of default demographics, whether we want to include those fields or recipes or whatever, I would think you would want gender, , nationality, ethnicity, possibly country of residence, disabilities, veteran status.

I I think those are all things that people track publicly as part of organizations. Age may be something we want to provide as default fields, but I don't think we have to go crazy.

So I don't think we have to go crazy with running a ton of them as long as they're not default or required on a contact, right?

Like, if create a contact, they shouldn't be required to add all of these properties. Maybe they exist as optional properties, but I shouldn't be required.

We have a birth date and, like, death date on all contacts, and then age is a derived field. Yeah, I mean, that's deficient.

Yeah, I'm just saying that, like, I wouldn't go crazy trying to define everything. And I think those are the typical things.

And as long as you're creating them as fields and they're not necessarily available by default, that's fine. So demographics, generally, yes.

But specifically start, like, birth date, death date, and your age are on every contact. Yeah, that's fine. Yeah, I mean.

I hope death date is a bad degree. I want to make sure we're on the same. Yeah, yeah. I think the point is that I think it makes sense.

can change the label so it's not death date, which is kind of creepy. Yeah. I don't know what else you'd call it, but yeah.

Termination. Well, it's different based off of different what the contact type is. Yeah. Anyways, I think moving on from this, I think it makes sense just to include them for now, and we can see if they really provide value.

See you guys in a couple weeks. Thanks. Bye, Scott. Who would like to stick around and work on some requirements, documents, documentation?

See a few people not leaving. to hear about profile. Subtypes? Yeah, you want to, like, I don't know, demo what part of profile you think is useful?

Steve, that was a pretty aggressive way to phrase it. So to frame this for anybody who's not familiar with the issue, the issue queue, there had been discussion around.

created a feature request on CRM for the ability to have subtypes or subprofiles of contact types. So, for example, a person might be a volunteer and or an employee and or...

it's think that if you're you're So I'd say, no, Steve, I'm not. going to go install Profile right now, but conceptually, right, I think that was the idea.

That was sort of the driving force, and, you know, it's something that other CRMs provide for, and I think would be valuable.

When you talk about this volunteer thing, what are they volunteering for? What is it? What's the purpose? Explain it to me.

You're going to say they're volunteering for an organization, aren't No, I wouldn't. I would never. I would never set up an argument where you agree with me and then you then are stuck in a position where you're in a corner.

I would never open up a discussion like that, JD. So I'm glad you brought it up or didn't bring it up, Steve.

So yes, a person might have a relationship with an organization as a volunteer for that organization. And there may be fields associated with that relationship, right?

Their volunteer profile for that organization. And I think relationship makes perfect sense, right, for tracking that kind of thing.

But a person might also be more generically a volunteer who has certain skills as a volunteer, not associated with their relationship with any given organization.

And so that's an example of there are fields sort of about a thing that a person is, but that not all people are.

That I think basically the concept. Except of volunteering for the organization that the member platform install is for, right?

Well, that's contact one then. No, that's the question. Is contact one us as the installation? And then, yeah, you could have a relationship to that.

But that's the question of, that doesn't mean someone might not create a contact type of volunteer or want a person's persona to have a set of fields based on a set of checkboxes for, right, whether they're a parent or whatever, right?

And, you know, I think there's some questions about how you might want to handle that. But there could be a case for scoped fields that have, you know, profile.

You know, someone says they have a disability as a checkbox on a contact you want to show a drop-down for what's your disability, right?

Now, obviously, we want to do that as a demographic, so it's different story altogether. But some dynamic fields based

That what you're getting at there, right? Right, JP? Yeah. Yeah. So to avoid having to have different contact types to support this, which would be problematic because then if you have somebody who is both a volunteer and also a...

Mechanic. Mechanic. Great example. Right? You don't want them represented as two different contacts. You want them as one contact that has the fields that volunteers have and has the fields that mechanics have.

Mechanic. I mean, I think we really want the idea of, like, scoped field visibility, right? almost not field permissions, but when you check this checkbox on a person, right, you say their expertise is mechanic or their expectations...

These are sales, get some extra fields on contact for those fields, right? So the idea of like a dynamic field visibility.

Is that true or no? So instead of having a separate entire profile for them or separate contact record, you just want the fields and properties to be on the same record, right?

Well, I've chewed around with that idea. I put in Slack many months ago something very similar to that, where you'd have like a config type that would denote a subtype, and then there would be fields associated with that subtype.

So if the contact has it, it basically just shows and hides the fields. But it's not really an elegant idea.

I don't really have a great critique outside of that. Yeah, mean, I've done this in things in the past using like field groups.

Which is not great, but hiding a field group on a form based on some inputs higher up above in the form, you you select the type checkbox of what they are and you show additional fields.

I mean, it can also be done with whether they're profiles or additional contact records and relating to contact records as aliases, right?

You could say this is a person, they're also as aliased to this other mechanic contact type or something like that.

But also the question is, then you update their name on one, does it update across all of them? I think there's a bunch of complexity to having duplicate profiles unless they're, you know, subsets of information and only the relevant additional properties.

To add another complexity to the mix, what if there is a field that is, say, common to mechanics and, I don't know, mechanical engineers or something, right?

Whether you're right-handed or left-handed.-handed. Or a freak. That's the third option. Steve, I don't think that's the technical term.

I think you're thinking of ambidextrous. Well, say, for example, maybe for a three-armed alien. Well, we have concepts like a degree, right?

You have this, you know, a contact doesn't necessarily need to have a degree, but once you mark them as a mechanic or, you know, employee, you want to know what college they want.

They know what colleges they want to, right? That becomes an available field, whether it's through a profile of education or something else.

Steve, do you have a comment about relationships? Oh, I have several. I have several. But I was really hoping that you would install Profile and then demo it for us live, JD.

Yeah, I mean, the concept is putting all the universities... And the question is, you putting all the universities in, is all the possible universities in as contacts so you can have degrees, right?

Well, so we've also discussed the idea of relationships where contact B is optional. So you could, you know, in theory, have a relationship for education, right?

And you could select what degree you got and the university could be filled in later. Yeah, make sure it could be a text field and not a contact relationship.

Like you could have the relationship, a relationship without the entity, without the parent, right? And the parent could just be a text field of enter university name.

I wonder if there would not be value in just creating the university as a contact. But, like, that's sort of an intuition thing.

I think that depends on who's case. I mean, I think the interesting scenario for the optional contact B on that relationship is you don't know what that contact B is, but you know that one exists.

Well, I mean, I have a degree from a university, but we don't have information about which universities. Oh, I do.

I do know which university you went to, JD. I do. It's under research. Yeah. Well, my question is, yeah, you would have them fill out a form and they say they went to, you know, Yale, and then do you create a contact for Yale, even though you're never going to contact Yale?

I mean, that's really, I think, a site builder thing, and perhaps there could be value in having a text field there instead of creating one or making it be a config.

The story about having contact B, the optional, is still out there, so, right, there's still questions around it. Now, if we just ignore the idea.

idea for a moment that there's like this contact A and contact B thing, right? There's this concept of a volunteer, right?

There's this concept of employment. I don't know about a volunteer having a workflow, right? You're sort of either volunteering or not.

Perhaps you might have like a, they have to go through some sort of prep program, right? Before they can actually do work.

But let's focus on employment since that one seems more immediately grasping. Like a workflow, right? You'd have, you know, applying or part-time or full-time or terminated, resigned, laid off.

And there might also be another field on there for like salary. And it might be a floating point number.

could be a select range, right? I'm not set on what those things would be. But you are able to create more relationships.

So if someone has two part-time jobs, right? And I could see a way where you could, I don't know, sum the two incomes together.

Are we still talking about the core CRM, or is this kind of like a slide module? That's a good question, JD.

Don't we also have contact details, which are fieldable entities? Yes, but those are a different type of fieldable entity.

We were talking about another fieldable entity. Well, I'm saying that your Steve, do want talk about what contact details are and what they're for?

Yeah, well, your education is a contact detail, right? In some ways, right? So I guess the question is, we could nitpick every single possible property of a contact, but I think something like education might be just a detail that you create with the right fields on it, right?

Or unless there's, I'm not. I'm just fully understanding the goal of contact details. You would be contacted in some manner with the details on that, either by snail mail, email, or some sort of form of telephony.

Okay, so it's typically contact info, like how I contact you, not just scope of some set of fields on it, contact.

Yes. It's almost like we should call it, like, contactable detail or something like that. contact info? Like, you could call it contact info or something, contact information, which would then be actually what it is, right?

That's a more common phrasing of it, isn't it? And your contact, you know, phone number, contact information. It's tricky because information is also just a very generic term.

Let's use data. Yeah, contact data is fine. Or maybe we can make the label, whatever we we want. Contact Epsilon?

Just coming up with a Greek term. I was going to go with the Ateskaton, but aren't you impressed with my few words of Greek I know that I've mispronounced already?

Never. Sorry, back to your question, Rich. So if contact details or whatever we call them, right, are, I mean, they're designed to be ways that you contact a contact, but they're more, like, I don't think we actually document that necessarily.

That's, this might actually be the first time that we've fully discussed that. The, the, the fields that we ship or the entity, the contact detail types, right, that we ship meet that profile.

@1:28:54 - JD Leonard (modernbizconsulting.com)

But the, the reason that we created them was because we felt like those. Things needed to have metadata associated with them, right?

What kind of email address is this, home or work, right? And I think it's... a geocoder to an address field.

Right, right, right. So I don't know. I could see there being other use cases for having, you know, fieldable information about a contact on there.

Like you suggest, Rich, somebody could do that for education. But I don't know whether that would be preferable to just having fields on the contact or possibly a relationship.

Of education, you can have multiple degrees, know, bachelor's, post-grad, you know, doctorate, whatever. So that's actually, you know, a concept when you would need types, but something like employment, maybe not.

We're not tracking, you know, what level of... Employment you have, just current, non-current, which doesn't necessarily follow that schema, like you're saying.

I mean, if we're going to start going to that level of thing, employment becomes its own entity, kind of that, you know, for each employment, you've got an end-to-end, a start date, you've got sort of salary or whatever.

Like, that to me is getting into different sort of module level, personally. Yes, I mean, that's another advantage. Very attentive to this.

Yeah, we're not building an HRM on CRMs, we're building CRM to manage contacts, you know, yeah. In the case of contacts, yeah, if you work for an organization, that's a relationship to another company.

The question is, how much do we need to know about it? Well, I mean, relationships are fieldable. And if we do some sort of voodoo in the code, and depending on how we choose to lay out the contacts, how those for pareer, before?

We just may try to lie to the end user and make them believe that it's part of the same entity in the same way that we kind of do that for contact details or contact info, contact information, communication details.

Steve, stop throwing out ideas. We've decided on names. No, better names are better. The only things that are hard in technology are naming things and caching.

Communication detail speaks to me somewhat, although I'm still not 100% convinced that it should be restricted by convention to ways to communicate with somebody.

Well, I think to our point, there's four is you could actually have both. You could have communication info as a, its own type.

And then you. You could move what is contact details now to be contact info, and then you could actually have the contact detail thing that replicates what a profile is, or just use profiles, if that's the chosen path.

That actually is that subset of fields that has a particular scope, which is the question ends up being if there's overlap, how do you handle that, like, you know, education or certifications or whatever it may be, where do you actually track that info, which is probably its own.

Detail or something. It's all tricky. I don't know how we best move forward on the question of subtypes for contact types.

It's not an immediate concern. No, I agree. Yeah, mean, I question if we should have just started with profiles, if the CRM should have just been a collection of profiles in the first place.

That dependency on the user entity, which... Does it? Does profile require user? Yeah, profile is necessarily a user's profile.

owned by users. Even though you can have anonymous ones in commerce. The consults, have anonymous ones. If you check out an anonymous user, you still get a profile that gets attached to the order, but you don't have a user link to the profile.

Anyways, you can figure that out in your head later. But if, yeah, maybe there's an actual dependency in the code because profiles, there's profile access based on who created it, essentially, who owns it or who the user is it's for.

So profiles may not be what we want no matter what. I think it's also interesting to think about, I mean, I think a general, some sort of general purpose way to have fields be grouped and optional, right, for a given contact, right, whether that is, whether those fields live directly on the contact and are grouped after the fact, or whether they live on some other fieldable entity that's associated with the contact, right, like, we kind of, we will need to do something there, right, to support various use cases, but it sounds like maybe we've lost our steam to talk about that any further.

It feels very, too far inside the future to eat as easily categorize. This is where it's easier once you start eating your dog food.

Steve, is there anything else? What's in the sort of beta blocker or more imminent need that you want to discuss while you've got some people?

Probably the issue that's keeping us from a beta release the most is having primary entity reference tested so we can know what we should do with that one.

Right? We should know what its limitations are and whether we're comfortable moving forward or not. There are like two like relationship related feature requests, you know, but to be honest, they don't really matter.

They could not be beta blockers at all. We could just release without them. For those last two, it might be worth flagging in documentation.

At least, right, that they're sort of under consideration. So because if a module wanted to extend CRM, and they're sort of working under the assumption that a relationship necessarily has a contact A and a contact B, for example, well, their world would be broken if we change that.

No. Why would it be broken? If they make an assumption that there is necessarily a contact A and contact B, and they rely on those existing, right, for some functionality they provide?

Well, I mean, these all... It's like we'd be changing the contract of what a relationship is. Well, it would be configured in the relationship type, so...

Oh, I see what you're saying. A different relationship. Each relationship could define whether or not contact B is optional.

It So And, you know, the details about that. Well, the other question I have is what is contact A and what is contact B in a relationship, right?

Let me make it even more confusing for you. Contact A maps to delta zero of the contacts field and contact B maps to delta one.

Yeah, well, exactly right. So, you know, if you're saying there's a relationship between a user and an organization, right, or a user and a company, it's their employment relationship, who's employed by who?

I mean, right, that's all defined in the relationship type. You define a label for contact A, a label for contact B.

define what contact types are available. Yeah, so if someone is expecting that, you know, relationships B doesn't exist, you only have one relation.

Relationship, you know, how do decide that? I guess the answer is that you might only have, you know, I think of relationships often being parent-child, right?

You know, you are a member of an organization or you're employed by that organization or, you know, the parent of a person or, you know, they're your parent, right?

Where that zero and one is not necessarily directional, right? If, for example, you have a parent-child, right, and you want a parent's phone number, but you don't have a contact record for the parent, sometimes you do, sometimes you don't, how do you handle that, for example?

And you just want to have the parent's phone number as a field because you haven't gotten the parent's info yet, right?

And now if you write a script that expects that relationship to exist with two ends, two contacts, someone's view or export script or something that they extend ourselves.

If they install it now and we add it later and it's optional, we haven't changed the default behavior. Yeah, I take your point, Steve.

Go ahead, Rich. I mean, I guess my point, I said maybe because just because we've configured something now that works a certain way doesn't mean the client doesn't expect it to work a different way.

And in my opinion, a relationship, I would expect to always be linking two items. I would never expect it to be open-ended, right?

I would personally think a relationship, I'd be against having the second pair of a relationship. If they install it now and we add it later and it's optional, we haven't changed the default behavior.

Yeah, I take your point, Steve. Go ahead, Rich. I mean, I guess my point, I said maybe because just because we've configured something now that works a certain way doesn't mean the client doesn't expect it to work a different way.

And in my opinion, a relationship, I would expect to always be linking two items. I would never expect it to be open-ended, right?

I would personally think a relationship, I'd be against having the second pair of a relationship. If the optional, I would actually recommend that we don't use the same field track and have deltas.

would actually have explicit fields on that relationship. Would you have explicit fields on the relationship? Well, so like my point is that I would actually have for an employment relationship, employee and employer as dedicated fields, not just labels.

Right. Or an employed by, you know, maybe you have a person, you have a contact and you can, the relationship is employed by X.

that's. Well, that would be an entity field relationship from one entity, from one contact to another. My. So you would have a relationship and that the relationship record would point to both with explicit fields and not just use a delta to define that relationship.

Because my take is that I would have that as an essential field because you actually could, in your employment relationship, have your manager.

Your subordinates define there as that employment relationship, and just having two contacts is not necessarily sufficient to define that relationship, if that makes sense?

No, I think two contacts is sufficient. I mean, if you use dedicated fields, you then can't query the relationships.

By having them be the same fields in all the bundles, can then query the relationships along to which. So my argument is that, you know, we both work for the same company, but I also work for another company, and now I have an employee, say, I work for you or you work for me, we have that relationship.

Now the question is, who do we work for? We would work for an organization. Yeah, but we both have, like, I have a relationship to, how do you define based on a relationship, employer relationship?

Yeah, there would be three entities, right, for that employment. You would have two, and I would have one. Yeah.

But how do we know that? So there's another relationship between us that says one's managed by the other, right?

Yep, that would be a fourth one. And how do we know that that applies to what company? I mean, both people would have the relationship to the company entity, right?

So say we're both employed by both companies, or we both work together as a company. The relationship about being a direct report of somebody else could have, it's fieldable, right?

So you could add a field there that references an employment relationship, potentially for each party, if you needed that.

And like, I think if you wanted this to be a full-blown ATS, that, yeah, that's just a different sort of system.

That, to me, just sort of said. We just don't support that, or kind of, that we don't have kind of, like we're not gonna, I'm just trying to understand this use case.

SCREEN SHARING: Steven.ayers started screen sharing - WATCH

I guess my argument is that we're not enforcing in any way that contacts, that contact A in a relationship will always be the person who is employed, or the person who is volunteering, or the person who is, right, as a volunteer.

Here, are, well, on an individual case you are, but on an individual use case, maybe I don't know about the code, but on an individual use case, could you have two different relationships, right?

One being volunteer, and one being an employee, and on the volunteer one, Delta Zero is the employee, and Delta One is the employer, and on the volunteer...

Delta 1 is the, or Delta 0 is the organization, Delta 1 is the volunteer, the person. So you run this report, and people are always in column 1.

So this is Contact 2. It has an employment relationship with Contact 1, which is an organization. So let's, if we take a look at the form here, there are two different form inputs.

They're computed fields, but under the hood, they're stored as a single field for performance reasons. But if you were to make a report, if you were to make a second record that is a different type of relationship, say, volunteer, and you flipped the record for Delta 0 and 1, so that the employee was, or the volunteer was the second field that, you know.

So if these were flipped in this case, right, you've chosen to put volunteer first. But if A comes out second, and you run a report where A volunteers with B is now flipped in the report.

Well, so if you go edit this relationship, right, edit the relationship type. Nothing stuck, nothing is enforcing, well, I created this manually on my system, and I chose contact A as organization, and contact B as person, without realizing that employer was done in the reverse.

Right, so if you had this set up, well, because now if you create a view of people that are part of an organization, right, where organizations, create a view that provide contact A being the organization.

But it's not always the organization in field A, right? I don't know. So computed fields work in the form level.

So when you look at the form, have two separate fields and they behave like such. I understand. behave like such in a view, I believe.

But you can also set the view up to use just the contacts field itself. So you would like filter where the contacts equal your organization and relationship type, you know, is in whatever type you want.

Yeah, I mean, I think, I mean, think it's a nitpick, I guess, but I feel like it's not very clean.

My take on it is that I feel like if you were to create a view of those, it would be kind of complicated to create a view of people who are related to company A as a result of that relationship.

Then it'd be kind of messy to export that data. Maybe I'm wrong. I haven't played around with it. This case, it does surprise me that we've chosen this architecture because of that.

And I do understand why it's being chosen. I just don't fully, I'm not sure I'm fully on board with that decision.

But anyways, I'm sorry, probably just derailing this conversation. But the point here was, yeah. So the point here is that I feel like the expectation that there's only one contact now seems more viable, but also I feel like it's less logical to me, given how this works.

But I don't know. What are you suggesting? I didn't necessarily suggest anything to get back to where we were, which was about the idea of not having...

a second contact in a relationship. It seems more awkward, given how this all works. yeah. And Rich, that was definitely, it's a question mark.

It's like, hey, we see that there is, there are use cases where there's information to track about a relationship, but we, the piece of information we don't have is that contact B, you know, here's one way it could, it could be tracked.

And I think there is some unease, right, about a relationship that doesn't have its second endpoint. Yeah, and our relationships here are something custom to CRM?

It is, it is CRM specific. Okay, because there is, there is a relation module, and my understanding about the relation module is that the relation module defines A is related to B as A.

Concept, it actually is, you know, the concept of a parent to a child, basically, or a direction to it for all relationships.

And that would be sort of my approach here, but I don't know, I haven't actually looked at the code for that module either, so.

I'm not trying to understand the difference. Well, I guess the thing is that, to me, the idea of a relationship is kind of the, yeah, I guess the idea of just, like, what's the parent, right, is the question, right, is...

You mean if you had a parent-child relationship? Well, any relationship, typically, there is, I would say, a primary entity in the relationship, whether it's the parent or the child or the organization that you're part of.

I'm feeling like there should be some definition that, you know, some designation of which one is the primary side of that relationship.

What about something like a friend, a friendship? Yeah, well, mean, well, exactly. That's the one-edge case that I, yeah, I think there's not always that, right?

And, yeah, I don't know. We're two organizations that are partners in some way, right? Yeah, yeah, I mean, that's the question of what is a relationship exactly, and, yeah, I don't really think there's a one-size-fits-all solution here, probably, but as I said, I'm curious how the relationship module, our relation module handles this, but without looking at it's code right now.

Yes, your question is, does the relation module enforce that in all relations? relationships, there is one primary side of the relationship.

Or it could be a primary. I don't know if it does or not. It looks like the relationship module just has, I did pull up the code here.

It just has a count of possible relationships that probably works the same way. As this does. And to be clear, are you talking about the relation namespace?

Correct, yeah. Okay. Which, if it's already solved this problem, then maybe we should use that instead. I think the relations are fieldable, by the way.

So, instead of rebuilding the wheel, that may be something to look at. But it is marked as obsolete and without a release of a Drupal 8 version.

That's Thank Oh yeah, it does look like that. It is a Drupal 8 module, just not a, it was not upgraded to 9 or 10 or something, probably.

Yeah. Yeah, it looks like they still have a D9 readiness task. I think it is worth asking the question, though, right?

A relationship in CRM, what about it is specific to CRM? Yeah. Well, and how do, well, and more of how do they handle this concept of is, is one, you know, I don't know.

I don't know. I have to figure out A's and B sides to relationships, too, but all curiosities. No, it's, it's interesting.

Hmm. Yeah, I mean, I. I am wary of CRM building things that are generic, but having them just be CRM things.

I do wonder if this could be a more generic module, and then there is a CRM-specific restriction of the scope to just focus in CRM on.

Yeah, or provide in relationship types or something. But anyways, yeah, I wasn't suggesting we change the way we're doing things.

We're just thinking about wondering how other people in the Drupal space had done this in the past, was all I was thinking.

I always love those conversations. Anyways, I think I've derailed everything at this point. No, no, that's what this time is for.

This is our slush time. I wonder if maybe we should review some of the event relations. Related requirements that we were talking about before, Erica?

Sorry, I was starting to write the text message to James about kind of meeting up, so I have been slightly spacing out.

Could we just review what you were saying? Yeah, yeah, only thing I said was maybe we should move on to reviewing some of the requirements that we had pulled together around events, which I think Rich in particular would be interested in, and I think one of the things we found with this, Rich, and let see if I can find it here.

Can you give the link handy, Erica? Just one. Moment. Oh, is it events and member platform? CRM events spec.

CRM events spec, there we go. I'll put the link in the... So one of the things that we, you know, found as we were putting this together, and I say we, but it's mostly Erica, is that as we were defining what an event is, we looked at it and we said, nothing about this has anything to do with CRM, right?

Why would it? We're just defining an event. But I think it would be interesting to look at this in the context of, well, Rich has this event module, right, with a representation of an event.

So, you know, what's the Venn diagram of, you know, what that module provides versus kind of what we came up with?

And I should also add that some of what we came up with was not necessarily completely generic to all events, but may have been in the context of thinking about what member platform needs for events.

So we're not saying that all these fields need to be on the generic event. Event, modules, event entity, right?

But some of them could be added later. Or added by a member platform. Yeah, so I can start with just saying what event does out of the box, which is createy bare bones.

It provides an entity type, right? So that's fieldable, bundlable, so you can have different types of events with different fields.

There's a couple base fields, which are really, like, start, like, the event start and end times, if you have them.

It has a machine name field, which I'm not entirely sold on, but that's a different discussion, where you can actually, like, when you name the event, it will generate a machine name.

I guess the idea being, you know, DrupalCon 2025 is the machine name for DrupalCon Atlanta, right? And you can have that in URLs or whatever.

I'm not sure I necessarily fully agree. With that methodology, that predates my ownership of the module and maintenance of it.

But that's really all that event provides out of the box. I then created registrations, which is essentially a very another bare bones concept of, you know, relating two items together with some additional properties.

You know, it's just basically a relationship person to an event. And as a set of fields that go along with it, and or entity to an event, and optionally a set of fields that belong with that.

And then there's a separate module for ticketing, which buy a ticket through commerce, and then during checkout, fill out that registration form for that event.

So, and the event, or the thing that gets registered for, by default, will actually be a profile with it, with event registration.

So be able to select your profile. If you already have one, or create a profile, or swap out profiles that you want to type for the group, user, or CRM contact, or whatever you want, is an option.

But just from a high level, that's sort of what event does at the box. It's extremely high level for the most part, and the idea is if you wanted to build a conference, you could have a conference event, you could have sessions as events, you know, registered or paid for, subscribed to, favorited, whatever you want to do.

So on top of that, and then registration, the way that registrations work right now is you select an event type that a registration should apply to, right?

So if you have, you would have a different type of event, right, conference registration, which might have different tiers of registration, right?

You know, attendee, sponsor, whatever, speaker, and those would be different registration types that would apply in a specific type of event, whether it's a, Thank you.

And then we do the same thing applies to tickets. Ticket types had that concept of this ticket applies to these.

Actually, created tickets for an event, right? So you said, you know, tickets for DrupalCon are $600. And then tie it to a registration type that you would fill out when you, during the checkout process.

So that's sort of what we have. So it's pretty generic.

@2:00:25 - Rich Gerdes

And then I would think that member platform, probably pretty generic from the get-go. The question is, you providing default event types or anything?

More than likely, the concept of registering a contact as the default, you know, record, I would think. But you might not, again, have different registration types, depending on the events.

Interesting.

@2:00:57 - JD Leonard (modernbizconsulting.com)

Looks like my recorder has disappeared. like my recorder has Looks Um, that's because I technically have another event that I'm, uh, supposedly attending, but I'm not actually attending that.

So anyway, we've lost the recorder, but that was a helpful overview, So can you speak a little more to what event, oh, came back, to what event provides, like, uh, uh, as an entity, as far as its properties or fields or anything?

Yeah, I mean, so it's, it's a very basic field. It's, you know, event name, I think it's a start date, and then the machine name, right, a, uh, tokenized version of the, the label.

Um, and there's, I think a couple other properties, but, uh, I think those are the core ones that have to look at the source, which I don't have in front of me.

I have to know by, but that's by memory, what, what the defaults were. All right, I'll cheat and go look.

Yeah, mean, I'm on my, on my laptop again.

@2:01:56 - Rich Gerdes

Yeah. So. So an event has an author, which is a user ID.

@2:02:12 - JD Leonard (modernbizconsulting.com)

It has a name, a machine name, a status indicating whether it is published, created, changed, revision, translation, affected, event, date, which is a date, time.

as you say, that's the start. Oh, wait, there's also, it says date range as the square.

@2:02:49 - Rich Gerdes

So actually it is a, oh, it's a date range is what an event date is. Yeah, that sounds right.

Where you have a start and end date. That necessitates.

@2:03:00 - estevenson

That you have an end date, right? I think the end date is technically optional, but yeah, I'd have to, I believe it's optional technically, but, or can be optional.

It's an interesting question. It's an interesting design choice, right, of do you track the start date or do you track, well, I mean, here it's a date range.

Versus having a separate, you know, field for a start date and end date or a start date and a duration.

I wonder, I wonder what the relative benefits of each are. Yeah, I mean, I would probably, I mean, I think, I think that's, I would probably do start and end date because you can calculate the duration, but that's probably what you want to, in a lot of cases, that's what you want to display.

You could argue the reverse, I think. it's good. Oh, Good.

@2:04:01 - Rich Gerdes

Yeah, I remember for the event platform, Duration was more useful for their use case because they would have people submit events, and then kind of after they had been accepted, they would get put inside the schedule.

So the advantage of having Duration is that if you wanted to sort of slide around the kind of event start time, like you're trying to figure out how do I put all these events together?

Yeah. Duration's really helpful. You know, kind of like for meetup.com, which is just sort of like simpler interface because there you're not trying to kind of schedule events sort of against each other.

So from a usability perspective, it's easier to do sort of just start or end time. Though I think I haven't used meetup.com.

@2:04:53 - JD Leonard (modernbizconsulting.com)

I'm not sure if kind of can you like do an odd number of minutes. So like could you do like a 43-minute event?

Or do they sort of specify that it has to be inside like 15 minute increments, which is pretty normal?

Yeah, well, I mean, I can think of cases where you want, well, one of the big cases is flights, for example, whether we want to call them events or not.

But, you know, a flight doesn't, well, it has a duration, like a duration, but you actually have different time zones for your start and end of your event, right?

So I think there could be a lot of scenarios. You could justify a lot of things. And I think that you can always calculate the duration.

@2:05:37 - Rich Gerdes

if you're dragging and dropping, can say, what was the time of this shift both, you know, timestamps accordingly.

@2:05:46 - JD Leonard (modernbizconsulting.com)

But, yeah, I don't know.

@2:05:47 - Rich Gerdes

You'd have to look at scenarios. But, yeah, I don't know. So, my gut is saying, hey, every event has a start start date.

@2:06:00 - JD Leonard (modernbizconsulting.com)

I'll say I start date time, right? And the granularity of that might be the date, right? Or it might be some unit of time on that date, right?

It could start at midnight. It could start at 3 a.m. It could start a at 3.16. Right. You can have an all-day event.

@2:06:25 - estevenson

It could spend multiple days, though, as well, yeah. Or an event, yeah, an event on any number, you know, any number of days, and it may or may not have time within those days as, like, a relevant factor.

Yeah. Well, yeah, there's no reason we can't actually calculate.

@2:06:43 - Rich Gerdes

We could create a computed field for duration or vice versa. Sure. I guess the question is, other than not to nipic date, but are there other properties that are needed from an event platform or member platform perspective?

@2:06:57 - JD Leonard (modernbizconsulting.com)

I mean, certainly for member platform...

@2:07:01 - Rich Gerdes

Right, so some of the fields that we've talked about is tracking, actually, time zone as part of that, which could be relevant.

The format of the event, so online versus in-person versus hybrid, both. I know if we're talking about it accommodating flights, flights by definition have two locations, because you have a start location and an end location, and based on how we've currently designed events, they can only have one physical location and one virtual location.

Yeah, arguably a flight is actually, involves two events, which is takeoff and landing, which both have locations and times.

So anyways, I think flights are a bad example. representing a flight as an event does seem like. Yeah, that was sort of my take.

I was just saying that there are technically events that may span multiple days or something, right? Depending, I mean, I can think of a bunch of different activities, cruises, flights, you know, across state lines.

But I think we shouldn't get hung up on that necessarily. I think we can come back to that. The location is neat.

@2:08:29 - JD Leonard (modernbizconsulting.com)

I've left that out of event intentionally because I think use case is there and I want to implement the concept of locations.

I do think that Drupal could benefit from a location module that would let you create location types, country, states, whatever, and reuse them.

And then you could link events to locations. Isn't that like an address? Isn't there an address module? There is an address module.

Well, it provides an address field, but my concept of locations might be. More generic, right? If you have an online event, that's your location.

Your location is online for this Zoom meeting or this Slack channel, whatever that might be. But I was thinking location might even be more specific than an address, like, for example, a seat at a desk in a conference room, if you want to designate that, or if you're doing ticketing, you know, a seat in a theater, right?

Yeah, that's interesting. It almost blows my mind how one could create a sufficiently generic location to meet the various use cases for location.

As it relates to member platform, we brainstorm for location, right, is, well, depending on the format of the event, there may be a virtual location, and the only information we're kind of brainstorming for our 1.0.

@2:10:00 - Rich Gerdes

You know, the only information we would have about that is just sort of a text area with whatever information needs to be provided, right, for that virtual location.

@2:10:11 - JD Leonard (modernbizconsulting.com)

That could be, you know, it could be a wussywig field or something, so you can add a link to join or, you know, whatever is there.

But we didn't want to get too prescriptive about what a virtual location is. And then if you have an in-person component, then we said, well, then there is one physical location.

@2:10:34 - Rich Gerdes

And we liked the concept, kind of thinking in the vein of what meetup.com provides, of having reusable locations. So if a given group hosts, let's say, monthly event, and it's almost always at the same location, or it rotates between three locations, whatever, right, it would be nice for them to not have to re-input all of the data for those locations every time.

But instead, they could just choose.

@2:11:00 - JD Leonard (modernbizconsulting.com)

You know, from one of the previous locations they've used and referenced that. Yeah, and that's where my location entity comes from.

@2:11:12 - Rich Gerdes

But we had sort of decided that for a physical location, there are specific elements to that, whereas for a virtual location, it's just like text field.

Now, in a generic conception of that, I guess those could be different location types that are fieldable with the different things they need.

@2:11:34 - JD Leonard (modernbizconsulting.com)

Is that kind of what you were thinking, Rich? Yeah, I mean, that was my idea. don't know specifically what member platform benefits from, I guess, the same thing could apply to contacts, right?

This company has an office at location X, here's their address. But, yeah, mean, generally, yeah, would be just a fieldable entity type with bundles.

So, you could have different location types. I don't know if that makes sense or not, but. Yeah. It does.

mean, for a member platform, we would probably rely on exactly two location types, a virtual and a physical, or something like that.

Or maybe there's a third one, because we have a concept of a reusable physical location versus a one-time physical location.

Yeah, I mean, I think that makes sense as far as defaults go, right?

@2:12:21 - Rich Gerdes

You know, if they want to extend it and add office space or rooms, you know, they can go ahead and do that once they install it.

Yeah, and I think, you know, member platform is going to be much more opinionated than CRM, right?

@2:12:37 - JD Leonard (modernbizconsulting.com)

CRM is more generic building blocks, and member platform is more solution, right?

@2:12:44 - Rich Gerdes

You know, out of the box, meeting the needs of a lot of organizations. And while it's Drupal, right, you can customize things to your heart's content.

There will also be a degree of, like, let's simplify the user experience and the user interface and member platform.

We're trying to...

@2:13:00 - estevenson

Including users who can use Gmail, not users who can navigate all the structure tabs, you know, in Drupal and figure out how to compose things as sort of our focus, right?

We know there are those site builders and developers who are going to go and do that, and that's fantastic.

But we want to provide a sort of more scoped, restricted view for the simpler user. Yeah, absolutely. And, you know, a bigger organization who's renting out an event space might want to track rooms or something, but they probably aren't using member platform.

They're going to build that on their own, right?

@2:13:36 - JD Leonard (modernbizconsulting.com)

So I think... Or they may use member platform, and they also need to build this thing on their own.

Yeah, or they've extended member platform to support this concept of, you you might have rooms, right? And rooms might be in a building, you know, if you're tracking infrastructure or something.

But that's, you know, I think, you know, locations might even be, you know, infrastructure or something. But I think that's of scope for...

... ... ... Defining location types, I think, is something that can come later. Based on what we've defined so far, like, different meeting rooms would basically be a bunch of, like, reusable venues that, know, kind of, you would name one meeting room one, meeting room two, meeting room three.

So, like, yeah, based on what we've noted so far in Cider Design docs, like, it is a little bit opinionated in how you do it.

That's not necessarily defining how it goes under the hood, but, yeah. In terms of what the platform's trying to accomplish.

Yeah. And so what we said for physical location is it would have a nickname if it's reusable, a title, an address, a map where you can adjust the pin on the map, some venue information, you know, text area, and internal notes, which are just visible to the people who can create and manage the events.

You know, so, you But that is clearly quite opinionated and not generic to any event. Yeah, that makes sense.

We said that an event has a description and a summary, so like full information versus elevator pitch.

@2:15:17 - estevenson

That it has a banner, you know, a lot of this is optional, right? A banner image, an icon, and a status of whether that event is published or unpublished, and also a state.

@2:15:36 - JD Leonard (modernbizconsulting.com)

And, you know, I think this might need some massaging, but the states would be sort of redefined, I think, is kind of the goal in such a way that modules can rely on these states existing and knowing what they represent.

@2:15:54 - Rich Gerdes

So if the event is upcoming and registration is open versus if it is upcoming and... Registration is closed versus it is upcoming and it's just a drop-in, you don't need to register, versus it's a past event or a canceled event.

And I'm sure that list could be worked on, but we'll be curious about your thoughts on that.

@2:16:17 - JD Leonard (modernbizconsulting.com)

Yeah, I mean, something could be both registration, could be drop-in, but you also have registration up until the point you run out of spaces.

@2:16:26 - Rich Gerdes

Like, but that's the type of thing that I'd wait until people complain.

@2:16:33 - JD Leonard (modernbizconsulting.com)

Well, I mean, we could probably solicit more opinions on that. Like, I mean, I think your point of, well, okay, registration might be supported.

@2:16:40 - estevenson

Is registration required, or can you just show up?

@2:16:44 - JD Leonard (modernbizconsulting.com)

Right? Those are not mutually exclusive states, necessarily. Yeah. Yeah, mean, that's almost a text box that says registration, question mark, and they fill it in to describe that.

And, you know. The concept of, you know, settings, however registrations work, you should be able to set up, is available basically as a setting on the registration to say, you can currently register or you can no longer register, right?

@2:17:15 - estevenson

Yeah, or you can register starting at this time.

@2:17:22 - JD Leonard (modernbizconsulting.com)

Yeah, registration's open, not open, open for these types, not, yeah, exactly. And also, I don't think we want to require anybody to use the registration that we provide as part of member platform, right?

You could link to Eventbrite if that's what you want to do, right? I think we want to support those sorts of use cases.

And support, you know, pluggable registration, right? Even if that's a very limited concept of what that is, but have some way where you can, you know, have an external registration that's just a link with maybe some...

@2:18:00 - Rich Gerdes

Text, right, or more, you know, integrated registrations, which could, you know, leverage event registration, for example, or entity registration, whatever it is.

Either way, for a particular version, kind of like, I would say that we limit it to X, Y, Z.

Yes. No, we'll keep it simple to start.

@2:18:29 - JD Leonard (modernbizconsulting.com)

Simplish. Simplish. And so besides that, you know, we've brainstormed, but have not, you know, fully committed to requirements around, you know, we will have a page that lists events, right?

And we will have a page that has a calendar of events, and there will be mechanisms for managing events.

ACTION ITEM: Post CRM Events Spec link in Slack - WATCH

Yeah, I mean, there's, there's obviously...

@2:19:00 - estevenson

The required interfaces for those things. Do you a, can you send me a doc for, to the client? Yes, I put it, I put it in the Zoom chat, but I can put it in Slack as well.

Yeah, you could just send it to Slack as well.

@2:19:18 - JD Leonard (modernbizconsulting.com)

I don't know if I can get it on my computer, but, yeah. Yeah, I mean, I think all of that's very reasonable and supportable.

@2:19:30 - estevenson

Um, and then, you we kind of separated, right, from the stuff specific to an event in member platform, the event registration pieces.

Um, but I think, you know, we, we also want to kind of rely upon what entity registration provides out of the box and figure out, well, what do we need to tweak or add to that to kind of, you know, meet our needs as opposed to like, let's, let's, uh, reinvent the wheel.

Well, as we. Yeah, like, mean, I think we sort of ended up calling it like bundle of functionality, kind of exactly how it gets expressed.

@2:20:09 - JD Leonard (modernbizconsulting.com)

This is just trying to define the what we're trying to do, and then the how is kind of its own discussion.

Yeah. So, Erica, did you have any other thoughts and events or things we should bring Rich up to speed on?

Um, oh, I'm just going to look through the document myself. Um. That, yes, kind of, there's also the whole, like, user permissions thing, um, that kind of, you know, because, like, mean, right now you sort of want, you potentially want the ability that I can create my events and I can alter my events.

But, kind of, maybe I don't want someone else. To be able to alter my events. Can I riff on that?

Yes. One of the things that we talked about is that we don't really like the idea of an event being owned by one person.

Maybe there are different roles associated with an event. So you can be an event manager for an event. Um, and, you know, maybe even there's an event, uh, owner or something like that, who, you know, can set who the managers are or, or things like that.

And then you have attendees of the event. Um, so there, there's sort of these different roles related to the event, some of which are maybe represented in other ways.

@2:21:54 - Rich Gerdes

Um, and, you know, the, the group module comes to mind as a way to sort of represent having... Different roles with different levels of access control for users within an event.

And while we are tracking people as contacts, right, in CRM, as it relates to event registration, right, there are users who are taking actions to register people, to register contacts for events.

And we need to figure out, for a given user, who are they permitted to register for an event, right, for it, and that may be based on relationships, right?

So I can register other people in my household, for example, or I can register other people in my company, or I can register my boss because there's a relationship, you know, around delegation or something like that, right?

ACTION ITEM: Integrate Event Registration w/ Event Attendance Group - WATCH

@2:22:53 - JD Leonard (modernbizconsulting.com)

Yeah, absolutely. And event does have group modules for both management and attendance. We're tracking with management and attendance to an event.

Registration doesn't interact with the attendees group at all right now, but it probably should. That's something I should look at doing.

But, so yeah, we could have a group with different roles. That's probably an option easily for management. Yeah, think, I think we have to introduce some sort of access check for registration, can register permission, basically, you know, you can register, they can register B, right?

They can register themselves, they can register people based on like a contact registration or a contact relation, relation registration or something.

Then we'll figure that out. But then associate that with some checkbox on that relationship to figure that out. Yeah, we also brainstormed, you know, some different use cases of restricting registration for an event.

@2:23:56 - Rich Gerdes

So maybe you can only register for an event if

@2:24:00 - estevenson

If you are an active member, right, of the organization, of the site, basically, for member platform's sake, right, we are saying that there is one organization that is the organization of the site, and that's the one that member platform is sort of supporting.

@2:24:20 - Rich Gerdes

Maybe at some point, somebody will go extend it and say, now you can build a true meetup.com that has multiple groups, know, organizations that organize events and things, but we're trying to limit our scope somewhere, somehow.

@2:24:41 - estevenson

What other scenarios did we come up with? I think it was like, there was one around, you can only register if your contact is tagged with a certain tag, for example.

some sort of conditions validator. Before you can go on this higher risk event, you must have gone on three kind of others, and then sort of like, as the way that kind of you'd sort of represent that is after three.

Well, that's, yeah. mean, for example, you can have tiers, right? So say, for example, you have tiers of membership, right?

Three members, paid members, whatever. You know, you could have some property there. So what tier of membership do member you can attend this event.

@2:25:31 - JD Leonard (modernbizconsulting.com)

You could also kind of have blacklisted, like I know for the gym I go to, that if you miss three sessions that you have registered to, you know, kind of you lose the ability to register ahead of time.

Like you can still drop in, but, you know, kind of if there's space instead of the class. But yes, you lose the ability to pre-register for like a month because they don't like people registering kind of and then not showing up.

Yeah, penalized. Negative. So, yes, the ability for kind of, like, contacts to be tagged and for registration to have rules based off those tags was one.

@2:26:10 - Rich Gerdes

Then, yes, there was member status, and that was kind of, that is getting into, yeah, that's relationship with, like, the CRM relationship?

CRM member. Yeah, membership. That's, I was just blanking on the name. Well, and there are a lot of question marks around exactly how memberships are going to be represented.

@2:26:37 - JD Leonard (modernbizconsulting.com)

Originally, the CRM membership project was, you know, going to sort of have a separate, have some different entities that represent different components of the relationship, of a membership and stuff like that.

@2:26:51 - Rich Gerdes

But Steve and I talked recently, and we think, well, maybe it should actually all be based on a relationship, right, between the organization and the contact.

So, yeah. We'll back. And then there needs to be more information, you know, about that and related to that.

anyway, that's... Yeah, I was also thinking, I didn't mention this earlier, but the concept of registering for an organization, right?

@2:27:12 - JD Leonard (modernbizconsulting.com)

You know, you could actually leverage the registration module to register a contact for an organization or that organization one and then have an expiration date for registrations if it's paid for renewals.

For example, you could also then create a relation that depends on that and could auto-update or something, just as a concept there that you could actually use, you know.

You're saying a registration could represent a membership? In theory. I mean, you'd have to, you'd still probably want the CRM relationship, but it could duplicate that or track some additional information.

mean, have to, have you'd you'd you'd you'd to, Thank

@2:28:00 - estevenson

This is where the relation concept, three-directional relationship concept comes from.

@2:28:04 - Rich Gerdes

It's like, well, you want to relate the user to the group and the relationship or the registration kind of thing.

But yeah, that's interesting.

@2:28:15 - JD Leonard (modernbizconsulting.com)

We'd also talked about, okay, there's the CRM representation of a contact being a member of an organization. Um, but that membership may be derived from what I'll call a different membership, right?

@2:28:40 - Rich Gerdes

Let's say the membership of their employer being a member of a chamber of commerce, right? Or something like that.

And so by virtue of that relationship, every employee or every employee of a certain rank or whatever, right? At the employer has a membership, right?

With the chamber of commerce or is a member of.

@2:29:00 - JD Leonard (modernbizconsulting.com)

So, yeah, you can basically have a parent contact that has a membership that then affects its child contacts. Yeah, like a proxy, you know, a bridge or proxy.

And so there's a conceptually a different representation of the sort of overall membership, right, that triggers persons having a sort of, yeah, derived membership from that main membership.

Yeah, you can have one company, well, can have one company registering for your program, but then all its members get the relationship as a member of the parent.

@2:29:45 - Rich Gerdes

But then, yeah, it's conditional based on some other relationship, which could expire. Sounds complicated, but I'm sure we could figure out a way to implement it if we wanted to.

ACTION ITEM: Post CRM Membership dependent-relationship issue link in Slack - WATCH

Like a dependent, if you want dependent relations. Yeah, I'll find that. There's an issue with some outline to it.

Let me find that and link it for you. It'll make for some good bedtime reading. Let's see. Member. Oh, it's probably in the CRM membership namespace, huh?

Hey, look at that. It's the only issue there. Nice. All right. I'll put that in the, I'll put that in Slack for your future consumption, Rich.

@2:30:41 - JD Leonard (modernbizconsulting.com)

Nice. That's something also with, like, event registration we've touched on very briefly. Maybe not, maybe we may not have talked about it today, but the idea of guest registration, that I'm attending this event and bringing two guests.

Do we need to collect information?

@2:30:59 - Rich Gerdes

Do we need collect Thank

@2:31:00 - JD Leonard (modernbizconsulting.com)

For them, are they just marked as plus guest, plus guest, right? And how we track that idea of a guest registration, and, you if I cancel my registration, then my guests are eligible for, you know, to revoke them as well.

But then registration does not account for that. The idea is actually that you would fill out two, you would have guest registrations that you would add on to a separate registration types, essentially.

@2:31:25 - Rich Gerdes

But that's the best that I had done with registration, you just have a registration type for guest.

@2:31:30 - estevenson

But then, you want to make that linked to or dependent on the other registrar and clean that up if necessary, if someone cancels, right?

@2:31:41 - JD Leonard (modernbizconsulting.com)

Yeah, that's interesting. And I'm also thinking through, you know, maybe, yeah, maybe you're registering guests. Well, there are some different scenarios here.

Like, one is we give you the ability to reference their contact somehow, right?

@2:31:59 - estevenson

And so it's... Truly a guest registration in, you know, that sense of the word, right? You're just registering on behalf of, you know, registering somebody else, right?

And then also, like, what about converting a guest registration to a known contact registration, right? Or converting the guest to a contact or merging the guest into a contact somehow, right?

I don't know exactly. yeah.

@2:32:25 - Rich Gerdes

Yeah, like, yeah, like, yeah, like, but really some approach would, be that if you do a guest, we just create a contact with unknown for the name and, or kind of like some type of that, and we tag it guest.

And then you've got... but I don't think we want a bunch of unknown contacts, like, polluting our CRM, no, no, no, that is the dumb way to do it.

Well, I mean, maybe not necessarily. Maybe that is a, it could just be a separate contact type, even, or something like that.

You could also just register the thing. Yeah, could also have it kind of eventually. that we have to have the concept of deleting a contact to begin with, and we're going to have kind of like event registrations sort of exist, like independent, like they're their own sort of thing.

So yes, like one way I could imagine is that you have a guest type, and then you've got some type of cron that goes around every so often, and just sort of deletes any kind of guest types that haven't been merged into somebody for sort of a while.

I don't know. Yeah, well, you can also just create two different registration types, right? You can have a contact registration and a guest registration, and both of them point to the contact, the same person, but because one is marked as a guest, we...

Yeah, that is a good approach, because yes, we've already...

@2:33:49 - JD Leonard (modernbizconsulting.com)

Yeah, and then you can at some point switch, know, change the registration type, you know, to register another person, and remove a guest, add a contact or something.

@2:33:59 - Rich Gerdes

Thank you. you. Thank We have to talk through that. Yeah, have somebody who's appropriately permissioned to be able to convert a registration of one type to another.

Yeah, and that could be the person doing the actual registration, whether it's you registering your guests or not.

@2:34:13 - JD Leonard (modernbizconsulting.com)

But maybe some certain events, right, we talk about flights.

@2:34:16 - Rich Gerdes

Again, for example, if I'm booking a flight, I need to provide the contact information for the other person who's sitting in the other seat.

It's not just me twice, usually, right? You actually need to provide that for the flight manifest so that TSA knows if that flight crashes, who was on the plane, right?

So there may be a case to not have guests or be able to register other people. There's a lot of use cases there, so we have to explore that.

But conceptually, it all seems logical. Rich, as you're working, thinking that a given registration type supports only one entity type as a registrant?

except is I don't ...

@2:34:59 - JD Leonard (modernbizconsulting.com)

... ? That would be my thought, and that's the way the code is written right now. I think the advantage of that is like a contact can have different bundles, so you could just say a contact of any of these bundles.

Right, about the selection too. Yeah, I don't actually track, one of the downsides of the way that event registration is implemented right now is I don't track the entity type of the target registration, and actually if I was rebuilding it from the ground up, I might build registration around the dynamic entity module, which does track.

Do you mean dynamic entity reference? Sorry, dynamic entity reference, yeah, which does track the machine, the entity type and the IDs.

can actually derive, oh, this is, you you could actually mix registrations on this registration type. You can have contacts and groups.

@2:35:53 - Rich Gerdes

I'm not sure if we really want to support that, but it might be something worth considering. Steve had some

Strong opinions on dynamic entity reference and its use in, I don't remember if it was RedHen or CRM Core or both.

One or both of those CRMs made the decision to have different entity type for an organization than for a person.

And his, I think his comment was that made a lot of things difficult because if you're implementing something for, like, to implement something for multiple entity types then requires jumping through, like, a lot of hoops to sort of support, you know, dynamic entity reference.

So I'm not necessarily suggestively. Yeah, I don't love that idea either. And one of the challenges, which is one of the challenges actually with registration and supporting anything to anything, right, is that you actually have to.

Define at some level what the anything can be and you have to be able to resolve that relationship. So like the way that I do this in entity registration is a little bit crazy is that you just have a generic like I create the base field definition for the registration and it references a user, which means that the column in the database is a number ID.

@2:37:26 - JD Leonard (modernbizconsulting.com)

And then I override the field definition as a bundle field definition and change the entity type, which lets you like Drupal know that for the form on the page, you get a different entity there.

@2:37:41 - Rich Gerdes

Now, I don't know. I doubt views handles this gracefully. I doubt other things handle this gracefully, but it's just conceptually how I did it.

And actually, it's how commerce does something, commerce tracks something that way. don't know what it was. It's types, maybe the or something, but I purchased entities on orders.

That's what it is. It's that way that Commerce handles the ability to purchase something on an order. And now, products or purchasable entities in commerce have IDs, numeric IDs, as defined by their API.

Technically, in Drupal, you could have a string ID of an entity, which would cause a database exception based on the way that registration is implemented right now.

But that's a topic for everybody. No, I think I filed an issue on DrupalCore around something that assumed that all the entity IDs were integers, but that assumption was not valid or something.

@2:38:34 - JD Leonard (modernbizconsulting.com)

I mean, technically, all of our entity IDs for config are not integers. You can't actually assume entity IDs are integers.

The thing we should be relating are UUIDs, which we know are strings, which opens another entire bucket of worms, and actually a module that I'd love to implement, and I've code started for it, which is UUID references.

I used to suffer from the same what is the entity type question on UUIDs.

@2:39:01 - Rich Gerdes

Yeah, if you're writing a view, you could probably make that assumption in the views config where you know this could be one of X, Y, or Z based on the field definitions when you make the views options for those relationships.

But yeah, you have to derive that somehow, which is kind of weird. Sounds complicated. It is extremely complicated. And slightly a nightmare.

And do not wish that upon anyone. Yeah. So a registration then would be for a specific entity type that is the registrant to a specific entity type that is the thing you are registering for.

Yeah.

@2:39:51 - JD Leonard (modernbizconsulting.com)

And you could choose, you could restrict the bundles, right, on either of those, presumably. Yeah. Yeah. Exactly. That sounds like a decent level of abstraction.

Yeah. I mean, yeah. I mean, I know, I think the relation module actually does a lot of this already, which makes me, again, curious if there's code I can borrow from that, if we're rebuilding registration.

I may look into that. But anyways, yeah. I think, yeah, the concepts of, like, who can register who and why and all that, that's probably going have to be business logic that'll have to live in the CRM event module or something.

I have to imagine that it will exist, or CRM or member platform event or something, some module that will represent that bridge.

@2:40:49 - Rich Gerdes

Yeah, my expectation is there'll be some sort of CRM, you know, probably CRM event registration.

@2:41:00 - JD Leonard (modernbizconsulting.com)

Module that takes, you know, entity registration and event and adds in the, you know, I'll call them restrictions, you know, for what we're registering, right?

@2:41:14 - Rich Gerdes

Contacts and guests, probably, but not users, presumably. And, yeah, would need to handle, you know, all the relevant access control.

So, plenty of work to go around. Always is. Very good. Well, I'm probably about to expire. No, no, no.

@2:41:43 - JD Leonard (modernbizconsulting.com)

I'm, like, increasingly, like, I need to eat food. Yes. Yeah, I went on mute earlier and walked down there upstairs to where the food is that evolved through digital here and got myself a plate of food and then came back down to where it was quiet.

Nice. Nice. Nice. But good chatting. think we're more aligned and aware of what we're talking about now. Yeah. So I think next steps on registration is for me to chat with John Oltman, and see about rebuilding and what the plan there is and what the requirements are, what our architecture is going to be.

Because I think, honestly, think starting from scratch may be the best implementation there and decide how we want to do it correctly and then support all the features and migrate all the features.

@2:42:34 - estevenson

I don't love the idea of not providing a straight migration path, but that may save us time and effort and a lot of things.

@2:42:44 - Rich Gerdes

Yeah. Yeah, yeah. mean, mixed feelings about that, obviously, but for the purposes of member platform, the sooner we get something out the door, the better.

Yeah, exactly. So we can leverage it. Yeah, we're, you know, it's interesting, like for member platform, we're kind of like, been over here in the ether of requirements definition for a very long time.

And what I'm finding that we're doing is we are then sort of forging relationships, right, with maintainers of different modules, and also sourcing volunteers to help, you know, contribute to those modules and maintain those modules at the same time.

And it's kind of, it feels kind of weird, like we have not created any code for member platform for very long, but at the same time.

I am still a complete Drupal noob.

@2:43:38 - estevenson

I mean, honestly, the goal of Drupal should be that you can build anything without code, right?

@2:43:43 - Rich Gerdes

Like, there should be a way to do events and be a way to, you know, do registrations, and you shouldn't actually, to build something like a member platform that should all just exist, there shouldn't be anything specific to member platform, right?

@2:43:56 - JD Leonard (modernbizconsulting.com)

But, you know, with the CRM contacts or profile. or whatever we want to make that. It's like the idea of link this to that, like using some existing tools.

Nothing you're doing as a member platform is necessarily unique. It's nothing that hasn't been done before in, you know, I built association websites.

Associations have membership. They have registration to events. You know, these exist. You know, it's just a question of building a standard distribution that doesn't in a standard way.

Yeah. And one that's sufficiently generic to meet lots of use cases as opposed to one organization's use case. Yeah, absolutely.

Okay. Well, I should let you guys, you should all get going. But it was good chatting. I probably talking with you and you're kind of like, you sound really good at what you're doing.

Hear, hear. I pass for it, I guess. Anyways. Yeah. Thank you. Thanks, y'all. Take care. Bye. Bye. Bye.