Member Platform (Zoom) Meeting on November 6, 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 6, 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)
• Paul McKibben (paulmckibben)
• James Shields (lostcarpark)
• Scott Wolpow (scottwolpow)
• Steve Ayers (bluegeek9)
• Erica Stevenson (speckles)
• Eric Wheeler (sikofitt)

What Topics Should We Discuss? / Limited Human Notes

• Recording
• Quick introductions
• (Steve) CRM
• Review open Beta Blockers
• Briefly review but not discuss demographics - discussion of demographics in two weeks.
• Discuss and Review Relationship issues.
• Theme
• There is code to set a different theme for /crm but there is no UI
• Where do we want the setting? On Appearance like Admin theme setting?
• CRM Event
• (James) Entity Registration
• Two approaches to integrate with CRM
• (Erica) CRM Event spec in progress

Action Items

Fathom AI Summary

VIEW RECORDING - 200 mins (No highlights)

Meeting Purpose

Finalize CRM beta blockers and spec out the CRM Event module.

Key Takeaways

• CRM Beta Blockers: The beta release is blocked by two issues: uninstall/reinstall stability and the external_identifier field, which will be marked "experimental" to unblock the release.
• Workflow for States: The Workflow module will manage entity states (e.g., email confirmation) via a new base field. This is critical because it allows for multiple, independent workflows per entity type (e.g., email confirmation and opt-in status), solving a key concern.
• CRM Event Spec Defined: The team defined the CRM Event module's "what" (data model, permissions) and "how" (using entity_registration for registration and Group for event management) to avoid reinventing wheels.
• Ecosystem Strategy: The core CRM module will remain minimal, serving as a "glorified address book." Complex features will be built in separate, optional modules (e.g., CRM Claiming, CRM Event Group) to keep the base simple and maintainable.

Topics

CRM Beta Blockers & New Fields

• Beta Blockers:
• Uninstall/reinstall stability.
• external_identifier field → will be marked "experimental" to unblock beta.
• New Fields for Discussion (2 weeks):
• Demographic fields: Optional fields (e.g., gender, ethnicity) based on ISO/Webform standards.
• Photo field: A base field for contact images/logos, with contact type icons as placeholders.
• Language field: To track a contact's preferred language.

Workflow for Entity States

• Problem: How to track multiple, independent states for an entity (e.g., email confirmation and opt-in status) without creating conflicts.
• Solution: Use the Workflow module.
• Mechanism: A new base field of type workflow will be added to Contacts, Contact Details, and Relationships.
• Benefit: This allows each entity type to have its own workflow, solving the problem of conflicting states.
• Integration: A custom plugin will bind the active/inactive status of a workflow state to the entity's core status boolean field.

Relationships: Schema & UI

• Schema:
• Optional Contact B: Allow relationships to have an optional contact B (e.g., knowing someone is employed without knowing the employer).
• Configurable Limits: Enable site builders to set cardinality limits on relationships (e.g., one "head of household").
• Multiple Contact Types: Allow relationship fields to reference multiple contact types (e.g., an "employer" relationship could link to an "Organization" or a "Food Pantry" contact type).
• UI:
• Improve the "Add Relationship" UI by providing a list of relationship types on the contact's Relationship tab.
• Clicking a type would pre-fill the form with the current contact as Contact A or Contact B as appropriate.

CRM Event & entity_registration

• Goal: Add event management and registration functionality to the CRM ecosystem.
• Strategy:
• CRM Event (The "What"): A module defining the core event entity, data model, and basic permissions.
• CRM Event Registration (The "How"): A module leveraging entity_registration to handle the registration process.
• Challenge: entity_registration assumes a Drupal user is the registrant, but CRM uses contacts.
• Solution: Adapt entity_registration to support contacts as registrants. This could be a significant contribution back to the module.

CRM Event Spec Details

• Core Fields: Title, start/end dates, location, description, banner, icon, and a new Format field (Online, In-person, Hybrid).
• Status vs. State:
• Status (boolean): Published/Unpublished.
• State (workflow): Upcoming, Registration Open, Passed, Canceled.
• Permissions:
• Initial Scope: view any event, view unpublished events, create event, edit any event, delete any event.
• Future Scope: Permissions based on the user's associated contact's tags or relationships.
• Event Management:
• Problem: Drupal's single "author" model is too restrictive for events requiring multiple managers.
• Solution: A separate CRM Event Group module will integrate with the Group module to provide flexible, event-specific roles (e.g., admin, manager).

Next Steps

• Steven:
• Resolve the uninstall/reinstall beta blocker.
• Mark the external_identifier field as experimental.
• All:
• Review the proposed demographic fields for discussion in two weeks.
• James:
• Continue investigating entity_registration to find a path for contact-based registration.
• Erica:
• Investigate the Event module and its extensions to identify gaps against the CRM Event spec.
• Install entity_registration to document its out-of-the-box functionality.
• Update the CRM Event spec with the new field and permission decisions.

Action Items

• Mark CRM external identifier field experimental for beta - WATCH (5 secs)
• Review demographics fields; prepare feedback for next meeting - WATCH (5 secs)
• Make CRM name fields optional; fix preferred name deletion bug - WATCH (5 secs)
• Implement CRM workflow plugin to map workflow states to status Boolean - WATCH (5 secs)
• Add configurable cardinality limits to relationship types - WATCH (5 secs)
• Implement CRM theme negotiator; add Appearance and CRM settings; default to admin theme - WATCH (5 secs)
• Add default image/photo field to Contact types; use type icon as placeholder - WATCH (5 secs)
• Investigate Entity Registration for CRM Event Registration; document OOTB; propose contact-as-registrant plan - WATCH (5 secs)
• Install Entity Registration via JD's recipe; document OOTB; update spec - WATCH (5 secs)
• Update CRM Event spec: add banner/icon, format, Internal Notes, views; remove virtual URL; clarify statuses - WATCH (5 secs)
• Investigate Event module + Event Group/Group Events; document gaps; follow up w/ maintainer - WATCH (5 secs)

Fathom AI Transcript

VIEW RECORDING - 200 mins (No highlights)

@0:00 - steven.ayers

Thank you. Good morning, Scott. Morning.

@0:47 - Scott Wolpow

How are you doing? Pretty good. And where are you based out, Steve?

@0:54 - steven.ayers

I'm a little bit south of Chicago.

@0:57 - Scott Wolpow

Okay. My niece in our house. We lived in Chicago, and we just had an oak brook or oak tree, don't know, one of the oak suburbs of Chicago.

I was there last May.

@1:16 - steven.ayers

That's rare. Most of our suburbs are lying about some sort of elevation, like Mount Olive or Mount Prospect. Just to be clear, these aren't mountains.

They're not even hills.

@1:30 - Scott Wolpow

Well, I live in Astoria, Queens. Actually, I technically live in Long Island City, but we call it Astoria. We're named after a person who they were hoping would invest in the area.

It never happens. But we make good pianos. And movies.

@1:52 - JD Leonard

Good. More than one.

@2:00 - Scott Wolpow

There we go. Is that an Austin City Limits t-shirt? It is.

@2:13 - JD Leonard

It's just down the street from me.

@2:20 - Scott Wolpow

You can see my neighborhood in a Bronx town, literally around the corner, even though it's not the Bronx. You see my supermarket in the movie, in the movie.

@2:36 - JD Leonard

Say again, Scott?

@2:37 - Scott Wolpow

If you watch a Bronx town, you see my supermarket that I go to. Nice. When I live in Forest Hills, if you watch the first Tobey Maguire Spider-Man movie, you see the other supermarket I went to.

So for some reason, Hollywood is obsessed with my supermarkets. Lady Shopper. Yeah, I believe it's November. Give people one more minute and then we'll kick it off.

@3:33 - steven.ayers

I imagine Martin's going to come to DrupalCon Chicago. Seems a foregone conclusion. So I think I'm going to get him a bottle of Crown Royal.

It's now being bottled in Illinois, so.

@3:53 - JD Leonard

It's local. Yes.

@4:01 - steven.ayers

Technically, it's still considered a product of Canada, since it's made with Canadian grains, and the warehouse that it sits in in barrels might also still be in Ontario.

@4:18 - JD Leonard

Very good. Well, let's kick things off. Welcome, everyone. Let's do a quick round of introductions, because we've got a new face on the call for the first time.

So I'm JD. live in Austin, Texas, and I am involved with my local neighborhood association, which kind of inspired the member platform initiative, as well as the local Drupal users group, et cetera, et cetera.

Yeah, glad for you all to be here. I'm going to hand it over to Steve.

@4:50 - steven.ayers

So I'm Steve. I'm the maintainer of the CRM module. Is everyone able to hear me? I want to make sure, because sometimes there's issues.

ahead. So, Ryan, I maintain the CRM. Yeah, we've got some interesting discussions today. Well, actually, no, not really. That's in two weeks.

But, Scott, you want to tell us a little bit about yourself?

@5:14 - Scott Wolpow

Sure. I'm Scott Wolpow. I'm an Astoria, Queens, New York. I've been involved in Drupal for many years. I was helping run the Drupal camps at one point when we actually had them.

I don't maintain anything, but I'm, you know, looking forward to documenting things and adding some things to CRM and to the member platform as I have needs for that.

So if I build something, I'll add that to the system, although maybe it helps on maintaining it because I'm not the best coder.

But AI is helping with that, fixing my mistakes. And I'm looking forward to this because I think we really need a good CRM and I'm stuck with a client who loves Civi CRM as such a piece of garbage.

And he does understand that. He thinks the greatest things in sliced bread. And I tried to explain to him, it's not good to have two systems that fight each other.

It's like Buddy Press and Word Press.

@6:18 - JD Leonard

Thank you, Scott. Well, welcome. Glad to have you here. I know Scott back from the Drupal New York Sea meetups back when I lived in that area, and glad to have you back on my calls here.

Paul. Hi there.

@6:33 - Paul McKibben

Paul McKibben, based in Atlanta, Atlanta Drupal User Group. I'm going to try and use Member Platform for that. I may have to drop out in another 10 minutes or so, so I apologize if I suddenly disappear.

@6:50 - JD Leonard

James. How are you doing?

@6:54 - James Shields

I'm James in Ireland. I've been involved in Drupal for... Quite a few years, but getting more into contribution and development side in the last sort of four or five years.

And I'm interested in member platform for a number of organizations that I'm part of. have a Lego group that I help organize and some science fiction conventions.

So I'm hoping that we can use it for that. And I've been having a look at the N2D registration module, which will hopefully be relevant for that.

@7:37 - Scott Wolpow

James, what sci-fi conventions are you part of?

@7:45 - James Shields

I've been involved in quite a few. I've been involved in a few in the U.S. So it's mainly sort of the literary side of science fiction.

@7:56 - Scott Wolpow

I know.

@8:00 - James Shields

Worldcons. We had a Worldcon in Dublin in 2019, and we're hoping to do another one in 2029, so I'm helping with that.

I've been helping with Eastercon in the UK. I've been helping with the Irish National Convention, OctaCon, and a few smaller conventions.

Yeah, they all died.

@8:24 - Scott Wolpow

I made you just be part of Lunacon.

@8:25 - James Shields

Oh, right. I was at a Lunacon...

@8:28 - Scott Wolpow

Icon, Philcon, Walkover, which really has another name to it, but I'll leave that off. I was at a Lunacon many years ago.

@8:43 - James Shields

It would have been very early 2000s, I think.

@8:48 - Scott Wolpow

By the airport or up in Rochester?

@8:55 - James Shields

I can't remember, because I was basically... Eh... Eh... Eh... Thank you. Let me redirect us, folks.

@9:01 - JD Leonard

Yeah, sorry, sorry.

@9:02 - James Shields

We'll talk about another time, John.

@9:04 - JD Leonard

Yeah, you can always peel off after the call if you like, but do you want to get us to our agenda, and I want to hand it over to Steve.

Take us away, please.

SCREEN SHARING: Steven.ayers started screen sharing - WATCH

@9:15 - steven.ayers

We got some items we'll take a look at. Right, you should be able to see a screen. Does that sound?

Yes. All right. So in terms of the things that are preventing us from our beta release, the actual, like, hard blockers, are this issue about uninstalling and reinstalling its related comments.

ACTION ITEM: Mark CRM external identifier field experimental for beta - WATCH

And then there's also one other item, I guess that it's closer. Yeah, this one. The external identifier field. I've been able to merge.

priceless. なんだ, of is Which, Thank Our code base. So the branch is at least current. There's more stuff that will need to be done with it.

I'm thinking we'll just mark it as experimental in a beta release. And if at some point we decide to remove it later, it was marked experimental.

ACTION ITEM: Review demographics fields; prepare feedback for next meeting - WATCH

That's sort of where I'm at with that one. But it's not installed by default. It's just available. Um, we do have some demographic fields.

We're not going to discuss them today. I encourage you to look at them and come up with some thoughts and opinions.

And in two weeks, we'll discuss them. Nothing's going to happen with them. They're not going to be added, like between now and then.

So, right. And they're all optional, right out of the box. None of them are on a contact. Uh, so, right.

Uh, anything here with demographic, eye color, hair color, uh, There are some standards out there, so that's where I was going with.

I don't know if we want to rely on the FBI in terms of guidance, but here's what they have.

An image or a photo field, this isn't really demographics, but this one might, I'm considering, might. We might add to a contact by default, right?

The idea would be each contact type would have an icon or an image, so like a person or an organization, and then each individual could have either a picture of themselves or a logo of the organization, and if they don't have one, the icon or image for the type stands as a placeholder.

ACTION ITEM: Make CRM name fields optional; fix preferred name deletion bug - WATCH

I don't know, thoughts, opinions. We already discussed this external identifier, right, for mapping contacts to other CRMs. They can sometimes be more than one contact in a different CRMs.

So there's some nuance to it. Apparently, if we were to delete the preferred name, I believe it is, there are some issues with formatting or something to that effect.

So we should make everything there optional. So you could delete the preferred name, an alias, the full name, right, and the person's still going to work.

Integration with comments. Whenever I put integration here, I mean optional. Why don't I just put optional? Well, when I say optional here, I mean you have to delete it, right?

But if comments are already installed and you install CRM, it will work. But if you don't have comments installed, we're not going to force comments to be installed by installing CRM.

Okay, let's get into the demographics that are going to make everyone uncomfortable. Starting it off, height and weight, not such a big deal, right?

But there's some modules that... That do physical stuff, like distance and weight. So that's probably what we want to integrate with if we're going to do something like this.

But certainly not a high priority. , right? This is going to, you know, I'm sure have plenty of thoughts and opinions on.

So as it turns out, there are standards by the ISO, so eat it. Right? So I don't know. I think it's pretty straightforward.

There's also a P for prefers not to say, but if the field's not required, isn't that essentially the same thing?

I don't know, right? Ethnicity. Ooh. So I didn't even bother to list the ethnicities here. I just pointed to the web project.

This is the ethnicities they have. So. Gender, right? I'm sure this is also one that will have many thoughts or opinions on it.

Here again, I just pointed to what web form had. I mean.

@14:24 - Paul McKibben

I would imagine that this is kind of, you know, not very many, maybe the other probably some, that would actually need these, that a lot of users of the member platform wouldn't even need these, correct?

@14:36 - steven.ayers

They're not enabled on anything by default. They would just be available. Be available for those who do need them.

@14:44 - Paul McKibben

Okay.

@14:46 - steven.ayers

Can I add to it?

@14:47 - Scott Wolpow

Some of them are pretty straightforward that have correct answers.

@14:50 - steven.ayers

Others are more subjective. I'm not saying we're going to add all of them. We're just going to have a discussion about it starting in two weeks.

about going going to about just discussion discussion it. We're just have it. A language field is sort of like...

@15:02 - JD Leonard

Steve, I think Scott had a question. Huh?

@15:04 - steven.ayers

Steve, for gender, can they add to it as we have more coming up? Yeah, so from the workflow, right, if you're going to be in field management and add an existing field, right, the UI shows you what the options are before you hit continue.

So if you want to add more options to gender, remove options from gender, that's all at the site builder's discretion.

I mean, I guess with the same thing with , maybe you might want to remove intersex or prefers not to say for some reason.

Or maybe you might want to include additional options under there. But where there's an existing and prolific standard, I think that's what the default should be.

But that doesn't mean we're going to add all of these. doesn't mean that they're all of equal value. None of these are beta blocks.

These are just a conversation we're going to have at some point in a couple weeks. Can I repeat how we're going to have a conversation in a couple weeks a few more times?

I feel like I haven't mentioned that enough. So a contact language field is what language do they prefer to be contacted in or what languages do they know?

I'm not exactly sure what the best way to implement this is. I could see this potentially being a base field, but probably not if it's included.

But it might be added by default just because that could be important. Just because you don't have a multi-language Drupal site doesn't mean that your constituents or the people you're tracking all speak the same language.

So those are just some fields. There's some stuff here with relationships we might want to actually have a conversation about.

So... So... So... I know, JD, you and I have had several conversations about how a relationship entity could look, and at one point we discussed making them either one way or making them optional, right?

You didn't have to have both contacts, but the way we had it structured at the time really made that not a great idea.

The way we have it structured now, instead of having it as two separate tables, two separate fields, it's a single field with two deltas in there, so two contacts, and delta zero just maps to contact A, and delta one maps to contact B.

So, we could make contact B optional, right, delta one. In some relationships, that kind of makes sense, right? You might know somebody's employed, but you may not know where they're employed.

Others don't really make sense. Everybody has two parents, so. So having two parent relationships without another contact at the other end doesn't make sense, but how many children you have isn't really set.

So like in that relationship, if we were to do this, you know, the child part could be blank so that the parent could indicate how many children they have, but not necessarily know any of the details about the children, right?

@18:28 - Paul McKibben

And I'd be careful about making a solid assumption of exactly two parents because, you know, situations where, yeah.

@18:36 - steven.ayers

Sure. There are exceptions where it's not like a genetic match. I'm just saying there's value in saying somebody has, say, three children, even though you don't know their names or anything about them, rather than saying somebody has two parents and you know nothing about them.

@18:51 - JD Leonard

I guess there's a, I guess there's an opportunity. You might, you might know something about their parents, but not enough to

To, like, add a contact for them. So, I don't know, having an optional contact B on that relationship could possibly serve some utility in some use cases.

I don't know how prescriptive we want to be. I'm not saying it necessarily constitutes a default.

@19:19 - steven.ayers

I'm just suggesting use cases for explanation. Understood. Right. You might know somebody's employee, but you don't know where they work.

But it's important to know if they're full-time employment or part-time employment. So, that's something we've looked at with relationships.

I don't know what people's thoughts are on that. There's some other things about relationships. I don't know if we want to dig into all of those or if we want to talk about this one first.

Oh, let's talk about this one first.

@19:53 - JD Leonard

It's complicated, right? And there's sort of this trade-off in some ways between... A simpler representation of some facts about a contact on the contact itself versus something that you can represent as a relationship, right, but don't necessarily, might not necessarily want to go through the steps to represent as a relationship, right?

So, like, employment status is an interesting one, right? Like, you know, yes, you could track that on a relationship, particularly an optional contact, you know, contact be optional relationship, but in many use cases, that's going to feel like a heavier lift than simply having a field on the contact that says employed, right, or type of employment or something like that.

And if you could have a calculated field, like, it gets, I don't know, I don't know how to, well, I guess I'm concerned.

@20:57 - Paul McKibben

I mean, to me, they're almost separate. Like, you have, whether or not they're. They're employed, and then who is the employer?

So one is a status, the other is a relationship.

@21:06 - steven.ayers

You are correct. One is a status and one is a relationship. There are other issues involving relationships, namely the workflow, which would then add a status to the relationship, I guess.

I mean, I guess the other question is, what would we want to name that status or not status?

@21:27 - Paul McKibben

know, whether or not it's even like, you know, these representations or these relationships need to be represented comes down to, I would think, you know, whether things you need to do queries based on those relationships, like everybody employed by X or, you know, everybody related to Y.

@21:46 - Scott Wolpow

So one of the things I'm looking to look for, what I'm going to be building out, is if you're working for a company, you should be to change your contact.

But they went upstream of you, your boss and their boss's bosses should be able to change. Contacts if they want to.

So what does that go in the leadership paradigm?

@22:06 - steven.ayers

So there's a different entity that maps a user to a contact.

@22:11 - Scott Wolpow

Okay.

@22:12 - steven.ayers

So like it has to be a person, right? You can't map a user to an organization. And then, you know, that person has a name, address, email address, that sort of thing.

And so permissions can be or we intend to grant through that relationship. Right, site builders can grant users permissions to update their contact info.

And you know what your contact info is based off that relation, that entity. It's not, I want to be careful about using the term relationship since we have an entity that's called a relationship.

So that helped.

@22:50 - JD Leonard

So to more concretely connect, to more concretely connect the dots for Scott, right? So there would need to be some mechanism.

Fathom, possibly that he would need to implement, right, that grants access based on a relationship, like a subordinate.

@23:11 - Scott Wolpow

Well, it's parent child.

@23:16 - steven.ayers

There is a. But it wouldn't be parent child in the sense of like, you are a parent, right?

@23:28 - JD Leonard

But I guess the idea is, right, the system should support that kind of flexibility, but might require additional implementation to get, you know, to your specific needs, right, within that framework.

@23:42 - steven.ayers

Yeah, we've got a feature request for letting contact access be granular based off of relationships. So, you know, in theory, you could have, you know, an actual parent child relationship where the parent can see and edit the child's contact.

I guess if the child had a login, they should be able to see at least the parent, but probably not edit any of the info.

And then maybe have that, depending on what your permission levels are, when you're editing the relationship, be able to override in specific use cases.

But we haven't touched it in several months.

@24:36 - Paul McKibben

I'm picking out loud here, but I almost wonder, do we have a set of use cases where various types of relationships would need to be represented, or do we need to find those use cases first?

@24:53 - steven.ayers

We have some defaults. Is that what you're talking about? Well, for example, the reason...

@25:00 - Paul McKibben

The we need the parent-child relationship is because we expect this type of organization is going to want to be able to allow parents to see all their children.

That's a use case. Or this type of organization wants to be able to see everybody employed by Employer X.

You if we can come up with some of those kind of concrete scenarios, it might, you that might be able to inform how we design the representation of a relationship in CRM.

@25:35 - steven.ayers

In terms of the default relationships, we looked at CiviCRM for what they provided, and they also have a type of access control on a relationship level.

So I don't want to be so, right, Linux says that they want to be POSIX compliant, but not Unix.

So we're trying to be like compliant. And at the feature level of what CiviCRM is, but it is, CiviCRM is not what we're looking to reproduce, right?

But I do want a migration script from CiviCRM, so having those as defaults makes it totally easier. And that's valid, too.

@26:20 - Paul McKibben

I wasn't aware of that. But yeah, having a migration from CiviCRM then kind of binds you to at least some of what CiviCRM tries to represent.

So I get it.

@26:35 - steven.ayers

So we can, I guess, think about whether or not we want to restrict relationships to be one-sided. But, right, that's a thing we can come back to, I guess.

@26:47 - JD Leonard

And so, Steve, with that question, right, the question is whether we provide the flexibility for relationships to be configured as having an optional contact B.

Yeah.

@27:00 - steven.ayers

It's not necessarily about which relationships we do that to at the moment. Sure, that would follow as far as the defaults, but.

@27:11 - JD Leonard

Okay.

@27:14 - steven.ayers

So here's one that's also about relationships. It is. Right. When you create the actual entity. Do we want one of the two contact A or B to either be defaulted to a particular value or make it required for a particular value?

So one use case would be for members, right? If maybe there's only one organization that you're tracking for membership.

Then you'd be adding a contact like a person to that organization in terms of membership. But you'd want the organization contact entity reference to always be that organization.

Or we could also have it where it could only be one of a handful of IDs or a callback function to handle that.

You know how, like, the list field works where you can input values, but there's also a place where you can put in a callback function?

Yes, Steve, we all know what you're talking about. Please continue. So, you know, something like that where you could decide.

So you're not, some relationships like membership do not apply to all organizations. Only some organizations have memberships, right? So that's what it's sort of about.

It's just a schema change in the config entity, not the actual database content entity.

@28:53 - Scott Wolpow

Steve, would that include, let's say I want to, I have a contact that's a client and I want to track this.

Sales, when they purchase something on the website, I want to be able to click on that and track their sales.

Would that be included in what you just mentioned?

@29:09 - steven.ayers

No, but it doesn't restrict it, I don't think. Or actually, no, if it's sales, it would be your client, right?

So one of the ends would always be like your company. So yes.

@29:21 - Scott Wolpow

Okay. Because in a company, you might have two links to that. One, under my name is the salesperson, and two, under my, when I log in, see my clients.

So I can see both of them. Or another case scenario would be that if there's a workflow integrations, in other words, did the person upload their documents?

we're able to track that.

@29:46 - steven.ayers

good thing that you brought up workflows, because that's another one of the issues that I want to talk about.

Steve, it's almost like you prepared for this meeting. You never prepare for meetings. You usually spend most of the meeting trying to come up with jokes.

Thanks, folks. folks. Thanks, Thanks,

@30:00 - JD Leonard

It's a good thing somebody prepared.

@30:04 - steven.ayers

So, yes, we were talking about, so I think maybe just in that use case you mentioned, it would probably be adding a field onto the, I guess, customer relationship.

don't think we have a customer relationship out of the box, but I mean, they can all be added through the UI, so it's not a huge restriction.

Do we want to talk about workflows? It also ties in with this contact detail confirmation state.

@30:32 - JD Leonard

Let's do it. Go ahead.

@30:37 - Scott Wolpow

Erica joined. Hi, Erica.

@30:41 - estevenson

Hello. Apologies for being late.

@30:46 - steven.ayers

So, JD, do want to give a brief overview of the request here? Sure, unless Erica does.

@30:55 - estevenson

Oh, I'm trying to sort of catch up to the conversation. Um.

@31:00 - JD Leonard

This was one that we worked on a call together on. But basically the idea here is that for each of the contact detail types, and we're starting from the perspective of an email address, right?

But you could similarly consider some concept of confirmation of address or a confirmation of a phone number. That it would be useful for some use cases to understand what is the confirmation state of this email address?

Is this person able to receive emails there, for example? And so that was the impetus for this request. And I think Steve is looking to direct us toward workflow for this.

@31:54 - estevenson

I added some mute music to emphasize the point.

@31:58 - steven.ayers

Yes. So you want a status, and I think that goes very well with a workflow, right? You have these different options, and some of them correspond to an active status and an inactive status, or a good status or a bad status, or my head being to the right or my head being to the left, right?

Some sort of metric. So, right, that's the status Boolean field. Or, yeah, it's on, like, all entities, contact or config types.

And here's this thing to remove the entity published interface, since we're not going to use that as an interface, but we're keeping the status field itself as a column.

You with me so far?

@32:41 - JD Leonard

Yes, but I have a big question for you, and that is, okay, that's great if the confirmation state is the only state I want to track for a contact detail, but what if I also want to track something like opt-in status?

Opt-in for what?

@32:58 - steven.ayers

Well, in the case of an email.

@33:00 - JD Leonard

address, for example, right? Like, have you opted in to receive communications or something?

@33:07 - steven.ayers

Seems like maybe a Boolean field or some other status that's not, some other data that's not a state or a workflow state or whether or it's confirmed.

@33:18 - JD Leonard

I'm just thinking, you know, you might have like a, you know, some sort of pending state versus an opt-in versus an opt-out versus no information.

@33:26 - estevenson

If I were to think of a complicated thing I can think of is I remember one time for a study that, you know, kind of involved when I see sort of DNA, it had so many different steps that, know, kind of, I am willing to kind of share it with this group.

I am willing to share it with that group, you know, kind of that, you know, sort of that for that.

And like, think it went as far as like kind of groups where anyway, it's just sort of like, yeah, for that opt-in, it was pretty complicated.

Um, so, like, I could imagine for events, um, that maybe involve that, where you've got, like, a whole series of sort of opt-in, still trying to sort of catch up to the conversation, but, um, yeah, that you could have, I am just trying to think, um, I'm, I'm, I'm going to pass it back to the floor as I try to get my thoughts in set order, sorry.

@34:34 - JD Leonard

What, what I'm, what I'm cautious of is saying, hey, for this entity type, we are going to use the status field to mean this, this other semantic thing, right, that is a type of status, but is not, like, the only possible status, you know what mean?

@34:53 - steven.ayers

I mean, you can have more than one piece of data on, uh, on an entity, but in terms of representing theр another personality.

It's status, it's a Boolean value, and it would then be able to be corresponded to a workflow value. So in broad senses, whether it's good or bad is what that Boolean represents, and the workflow state field is the detail information about that.

@35:19 - JD Leonard

But you can only have one workflow associated with the given entity type, right? Bundle.

@35:26 - steven.ayers

It's at a bundle level. At the bundle level, okay. So email could have a different workflow than phone number, be different than address.

Each relationship can have a different workflow, right? Marriage is a different workflow, right? You presumably get engaged, married, potentially divorced or widowed, and there's some sort of correspondence to the status of that relationship, right?

Employment is a similar thing. You're going to maybe go on a pre-interview process, you'll be employed. Let's Let's -time, part-time, and you'll either be terminated, leave the company, or some other thing that is the status of that relationship.

@36:11 - JD Leonard

If for a physical address, I want to track its confirmation status, as in somebody can receive mail there, and I also want to track its, I don't know, construction status.

Like, the building been built there yet, right, or what stage of construction is it in? Now I've got two different statuses, and what I'm hearing is you're saying we should track it all against the status field.

@36:41 - steven.ayers

No, I'm saying that your idea of, like, a building being constructed, I'm not waiving it as being impossible, just you would implement that with a different, you're going to be building a custom module, and you should probably be relying on the workflow project, which you can then just add another.

Another workflow field to it, but we need to not rely on dependencies, so having another hard dependency is not an attractive option, but furthermore, we still have to write a workflow plugin and make it available to the different entity types we're interested in.

So using the workflow field to represent this workflow base field, I don't want to repeat field, but there's not a lot of value there for us.

But if you're trying to track, in addition, something special like building a house or, I don't know, a dead body, that seemed a little morbid.

I was reading an RFP for the main department of financial, or not financial, some sort of crime thing related to the morgue, so I apologize.

@37:55 - estevenson

Yeah, no, mean, if I were to think of a scenario, oh. Kind of for voting, kind of like you had addresses, and they could be sort of like put like likely voter, undecided voter, know, kind of like definitely not going to vote.

And within kind of like the sort of organization, depending on that status for an address, you would sort of treat them differently on election day.

That, yeah, that we had stuff like, are we arranging a ride for someone? So kind of like for this address, you know, if they're a very likely voter, then we might contact them to kind of, yes, like, would you like a ride to the polling station?

I remember that there was kind of a stage where, oh, like we had a bunch of flyers to put on doors.

And so, yes, for those likely voters, we had, and not every single place was able to get this because you had to have volunteers for that.

But yeah, whatever. So, yeah, like, though the addresses would have status, I mean, I'm just sort of like trying to then map it to the field, because that's arguably a different field, an entirely different module, but if I were to think of a complicated use case, yeah, that depending on likely voter, not so likely, kind of never contact me again, and like addresses could sort of, the status associated with it could change depending on, you know, kind of you call someone and they say never call me again, or like that person's dead, or I don't know if that kind of helps trying to think of a sort of complicated scenario where there's multiple kind of workflows, or if this would divide a different way, just because I'm still wrapping my head around that.

@39:53 - JD Leonard

So, Steve, I probably should have read what you had shared on the screen here. You're proposing removing the status.

No, I changed my mind on that. Oh, you did? Yeah, no, I looked into it.

@40:07 - steven.ayers

I was thinking maybe it worked differently. We still want the status field, and we still want it to be a Boolean, and we want to keep it called the status field because in Drupal, that's what it's called.

You look at config entities, they all have a status field. It's all a Boolean. You look at a user entity, it's got a status field.

It's a Boolean. You look at a node, it's got a status field. It has a Boolean. I can keep doing this, JD.

There are comments. They have status fields. It's a Boolean.

@40:35 - JD Leonard

I don't disagree there's a pattern there. My question is, what does a status field mean on a given entity type?

So for a context detail type, what does status represent? How would somebody use that in a way that, let's say, some other contributed module would also understand?

And leverage.

@41:02 - steven.ayers

Good, bad, right? Like you're going to do some sort of bulk mailing. Is the status good, right? Positive, true.

Then it gets included. If it's false, it doesn't get included. Right? If you're doing a bulk emailing, you don't want to delete the email.

You want to have a record of what that contact's email is. But if it bounces, you want a way of indicating that it's not a good email address.

@41:27 - JD Leonard

That all makes sense to me. I think my concern is with the use of a single field called status.

Oh, that's the other thing.

@41:35 - steven.ayers

I don't want to call it status. Because, right, this whole conversation has been confusing because we keep saying status this, status that, status this.

So I thought it would be, you know, really good if we called it state because that's clearly distinctly different.

Steve, the way you're looking around and avoiding eye contact makes me think that's . I don't know. don't know.

You're

@42:02 - Scott Wolpow

So, if let's say, for instance, I have a directory where people claim their profiles, that would be a state.

If they claim it, it's now claimed, and that'd be yes or no, because it doesn't really need to be anything else.

Like a Yelp. If you're a directory like Yelp, and you say, do you own this business? You go, yes, it gets confirmed.

Then I, as the owner of the list, can see who's confirmed, who's claimed their statuses or not, their profiles.

@42:31 - steven.ayers

Yeah, that seems like a relationship between, I'm not exactly sure which two contacts at the moment, probably the organization and the person.

But yeah, that would be like a status with a thing on it, I guess.

@42:46 - JD Leonard

I agree, that's the way to represent that that leaps out at me.

@42:50 - steven.ayers

In terms of, like, how would this work in practice, I'm not sure about what I want to call the field name, because, right?

That's going to be complicated. At first, I thought, you know, relationship status, right? Because there's moderation status or state.

But we're probably going to reuse this same concept on the relationships, the contacts, and the contact details. So I'm thinking probably just call it the same thing on all of them.

@43:30 - JD Leonard

And refresh my memory. It's been a while since I've dealt with workflow. So you're saying there would be a, if workflow is installed, right, then we would add the field or we'd have the option to add the field.

So it's going to be a base field.

@43:51 - steven.ayers

Okay.

@43:52 - JD Leonard

So it would be added.

@43:53 - steven.ayers

So, right, if you already have workflow installed, it gets included when you install CRM. If you install workflow afterwards.

If It gets added in response to it being installed. There'll be a default workflow where I think it's just going to be active, false, true, false.

I'm not sure what we're going to do with the verbs. Oh, active and inactive, right? So it would then parallel the status field if you really didn't want to have a workflow for that entity.

But I really don't like the way the content moderation module implemented. They didn't really use a field on the entity.

They did something else, and I don't really like it, is the short version. Also, the core workflow system gives you a workflow field.

I mean, could it get any or, yeah, a workflow data type, rather. So, right, you just define a base field with a particular data type.

So it's not like It's super complicated in terms of like reinventing the wheel.

@45:03 - JD Leonard

So you're envisioning, just to summarize, out of the box, if workflow is already installed at the time you install CRM, or if you install workflow later, right, then a field of type workflow, whatever it is, status, whatever it is, gets added to...

to each of, each contact type, each contact detail type, and each relationship type? Yes. And the out-of-the-box states are active and inactive?

With the exceptions of ones like marriage, employment, and things that we also provide. Oh, I see what you're saying.

Some of them would have more obvious... Yeah, but...

@45:59 - steven.ayers

Customizes. Customizes.

@46:00 - JD Leonard

And then, so if I have this other concept of state, I can simply add another workflow state field, name something different.

@46:09 - steven.ayers

So if you were to add this workflows field, you would then have under add fields, the option to add a workflow field.

And the difference between that and the base workflow field is that they add it to the UI and it's not required for everything.

@46:36 - JD Leonard

Sorry, I missed that. What's the difference between adding it this way versus the base one?

@46:41 - steven.ayers

This one requires a dependency.

@46:43 - JD Leonard

Oh, yeah, okay. But basically what I want to You could create a different workflow to deal with like a building being constructed or some other scenario and add it as a field.

Because there was something in a previous conversation we had that was like, you can only have one. And I guess you're saying with the...

Without an additional dependency.

@47:04 - steven.ayers

Well, would you really want the workflow field for whether a place is where it is in its construction controlling the Boolean status?

No.

@47:16 - JD Leonard

So, yeah.

@47:18 - steven.ayers

Great. Okay, I think we're good then.

@47:20 - JD Leonard

I think my concerns were rooted in this concept that all state things had to be in a single field on a given entity type.

ACTION ITEM: Implement CRM workflow plugin to map workflow states to status Boolean - WATCH

And so if you had multiple concepts of state, then those would, that would be problematic. But I believe you have alleviated my concerns.

No.

@47:40 - steven.ayers

The custom plugin that I have to write or somebody will have to write takes the workflow states and will bind them to the status field.

Right. So if you define a state that's, you know, active status, it will then change the status field when you.

So change

@48:04 - estevenson

So in the case of kind of, yeah, one scenario I can think of for, for a given address, though, mean, it's really for, for contact within that address, you know, kind of someone is a likely voter, or like a definite voter, likely voter, uncertain voter, not voter, would each of those things be its own kind of Boolean field that gets attached?

@48:25 - steven.ayers

No, those, I mean, you could implement that really any way you want, but that's not really related to state or like, that's like just a select field, right?

It's not like a workflow where you start off as a likely voter and then become less likely or, whereas, well, I mean, sure, people change, but it's not the same way that you have to be married before you can get divorced.

Mm-hmm.

@48:54 - estevenson

Or you have to be married to be a widow, right?

@48:57 - steven.ayers

Like, you can't. Yeah, no, I mean, kind of the.

@49:00 - estevenson

The one that sort of changes is either you haven't voted or you have voted, because, like, you know, if you have voted, then you don't want to give that person more communications.

Yeah, no.

@49:11 - JD Leonard

The big difference with Workflow, right, is with Workflow, you have transitions between states that are configurable. You can have different, you know, permissions or access control associated with, like, hey, who can transition this, you know, field value from this state to this state, right?

So it's just, it's a little more involved than you're just tracking information about something.

@49:39 - steven.ayers

And if we were to do this about a morgue, for example, you might have different states in that workflow for whether or not there's been detox, they've gone through the detox, or a tox screen, or I need to look at more material that aren't RFPs, I think, but.

ACTION ITEM: Add configurable cardinality limits to relationship types - WATCH

So here's something else. us about relationships thrown out there, being able to configure limits on them. So we talked about how there might be some scenarios in which a person could have more than two parents, but the general, you know, it's going to be two.

And if we're going to be honest, the third person is probably a guardian, not a parent, but whatever, I'm not here to argue that.

Um, these are configurable, so it's not like we're imposing anything as a hard requirement, just like the way fields have a, now JD's going to pronounce me because he speaks the Queen's English, but I say cardality, and he says some, some, something that's spelled incorrectly, I don't know.

@50:46 - JD Leonard

Cardinality.

@50:47 - steven.ayers

Ah, he pronounces all the vowels, that's the There's men in there. Um, so the thought would be, like, maybe if...

You only want to track somebody's one employer. I mean, this is less of a useful scenario, I think, but you are generally employed at more than one place throughout your life as opposed to, you know, having more than one parent throughout your life.

So you want to be able to have limits only on active relationships, perhaps. I'm not imposing or suggesting that we have defaults, except maybe on the parents.

Child relationship, but that's really more of a way of demonstrating it. I don't know. Just a thought, you know, not married to these ideas, but fields have limits.

Relationships might also have limits.

@51:54 - JD Leonard

Would those limits be enforced at the entity? Validation level? Yes. So it's not just UI-based validation, right?

@52:08 - Scott Wolpow

Well, can the limits be decided by the admin who creates this?

@52:12 - steven.ayers

Yes. Absolutely.

@52:15 - JD Leonard

So this is used to add the ability for a site builder to configure the limits for each relationship type.

@52:26 - steven.ayers

I mean, we talked about, like, head of household before. And I think in Civi-CRM, you can literally only have one head of household.

And so, in theory, we could implement the same thing. I don't really see a need to, but just. I could imagine site builders having similar use cases that we can't imagine where having only one of.

Like, if you were to, say, look at a state court system, right? There's going to be. be. There's There's There's you.

One, Supreme Court justice on a court of several. I don't know where I'm going with that one either. It's also an RFP.

So, yeah, actually, no, I was thinking about it in terms of like contact types. You don't want to create another contact type to represent a flesh and blood person.

But depending on what you want to represent, it might make sense to make different contact types for different organization types.

If the organization type, for example, doesn't actually have employees. Like the Supreme Court justice of a state is an employee of the state, not necessarily the Supreme Court.

And so, right, you have an employer, but if you're on a court, you would have a different relationship. I don't know.

It's just a hypothetical. It's not something that would be included by default. No, I agree.

@53:57 - JD Leonard

I think that there's, I think there's value. And I think it makes sense that you might have a use case to have additional contact types, particularly for organizations.

I guess you could have arguably different types of people, like you've got, like let's say you're tracking completely different information for, to use, you know, I don't know, like inmates versus guards or something like that.

@54:30 - steven.ayers

I mean, they're still going to have a name. The inmates obviously don't have an address they can control, so.

@54:42 - JD Leonard

But I guess, I guess more what I'm, more what that is shedding light on, right, is some, some people have used like the profile or profile two, you know, modules in the past to allow you to have sort of a different set of fields.

There are different types of users, right, or different types of people. And I wonder what the analogous sort of solution is for CRM.

I've stated an opinion that nobody, including me, likes, so there's that.

@55:16 - Scott Wolpow

To go with Steve's judicial things, in New York State, most judges are employed by the state in the bigger cities, but in the villages and towns, they're employed by the villages and towns.

Unless they get to a certain level of the Supreme or Family Courts.

@55:36 - JD Leonard

But in that state, in that case, regardless, they could have an employee-employer relationship between the two, right? Well, we'll stick a pin in the sort of profile types.

@55:52 - steven.ayers

Well, I guess that also throws in a sort of a, there's not really covered in an issue, but would we want to have a relationship?

Relationships allow more contact types, not contacts, but contact types for contact A or B. So just throwing it out there, if we, for whatever reason, thought that creating a separate contact type for food pantries made sense for whatever reason, would we want them to also be an employer?

Right, so employer would have organization and food pantries. So it's turning a single field into a sequence of fields to determine type.

Ooh, I'm not sure I followed you there.

@56:34 - JD Leonard

What I thought you were getting at was if we have potentially multiple contact types that effectively represent an organization, for example, right?

Okay, then would we want a relationship type, the reference fields to the contacts to be configurable for more than one contact type?

Yes, that's exactly what I'm saying.

@56:59 - steven.ayers

Okay.

@57:00 - JD Leonard

I I think the answer should be yes. Yeah.

@57:04 - Scott Wolpow

To another thought, if we're doing, like I told you before, hierarchical permissions, and there might be a case where a person will hire up in a hierarchy, like the CEO of the company, you really don't want give them permission to change things below them because they can screw things up.

@57:27 - steven.ayers

I think so, but...

@57:31 - Scott Wolpow

Or even in my kayak group, which I'm going to build a volunteer system for, you know, you might have a leader of a single trip that may have powers over that trip, but have no powers over any other trips.

That would have to be like a subgroup of the master group.

@57:50 - steven.ayers

I don't know if it's an, if it would be like an event then, or how... event, yes.

@57:56 - Scott Wolpow

Yeah.

@57:58 - steven.ayers

Well, events are, I guess... That's somebody else's problem. Where's that bus at?

@58:06 - JD Leonard

So just looking at the clock, Steve, we've got five minutes left on our time for the meeting. I wanted to see if anybody has a hard stop and needs to leave in five minutes or if we want to just keep running through the agenda.

@58:21 - Scott Wolpow

I'm good. I'm good.

@58:25 - estevenson

I was late, so I'll stay.

@58:30 - Eric Wheeler

Sounds good.

@58:31 - JD Leonard

Steve, you're good to keep going. This is really just a UI thing.

@58:37 - steven.ayers

Right. If you click Add Relationship, you get brought to some sort of page where you have to, like, fill in Contact A and Contact B, and that's kind of a bummer.

Right. So, I don't know, maybe on the Relationship tab, we have a Add Contact or Add Relationship button there.

Right. So you're on the Contacts Relationship tab, Add Relationship. It brings you. to a landing page where it shows you a list of all the relationships possible, right?

If it's a symmetrical relationship like siblings, it's only going to be displayed once. But if it's, say, parent-child, there'll be a listing there for parent and there'll be a listing there for child.

And so when you click on parent, the contact that you're referencing, right, will be the child and you'd be filling in the parent.

And when it's, you know, adding a child, your contact is the parent and you're adding their child, right? And sibling, it doesn't matter.

That's all it is, just UI stuff. That makes a lot of sense to me.

@59:45 - JD Leonard

It got me thinking about permissions of adding relationships that, well, obviously would necessarily involve a contact other than your contact.

Right? So just big picture, if I'm logging in as a user that's associated with a contact, and I'm, you know, permitted to add relationships to that contact, I am affecting other contacts in the process, how should I be permitted to add or remove or edit those relationships?

@1:00:25 - steven.ayers

Well, you'd have to have some sort of relate permission to create relationships to begin with. So, so it's a problem.

@1:00:34 - JD Leonard

It's a problem for whoever decides to add that kind of capabilities where you're getting that.

@1:00:39 - steven.ayers

Um, we haven't really gotten down to those sort of fine granular controls. There's just create, there's permissions to be able to create relationships.

And, uh, there are those who can't. And there's no granularity there. Well, you can be an administrator of CRM and create relationships.

And you can have the permission to create, I believe, any relationship, or... I don't know if we limited it by bundle because it didn't really make sense.

We probably should do it by bundle. Maybe, but, like, if you're doing data entry, I don't know. It's something to consider when we get to beta was sort of my two cents on it.

So those were the issues in my queue. I don't have anything else. I don't really plan the closing.

ACTION ITEM: Implement CRM theme negotiator; add Appearance and CRM settings; default to admin theme - WATCH

@1:01:40 - JD Leonard

You had on the agenda something about theme? Oh, yeah.

@1:01:47 - steven.ayers

So there's code that exists for a theme negotiator. In the project to change the theme from the default to something else for anything that's after CRM.

We can either add that to the appearance section like they have for the admin theme, or we can put it like on its own setting, like its own setting page somewhere for CRM.

That's all. It's not.

@1:02:17 - JD Leonard

I feel like maybe it could go in both places for discoverability's sake. Kind of annoying, but there's no, like, for your admin theme or the, like, default theme for the site, there's no other place you would want to surface it, but for CRM there is.

@1:02:37 - steven.ayers

I suppose. We probably want to default it to the admin theme if it exists.

@1:02:47 - Scott Wolpow

Well, would we not want our own dashboard that organizes everything in a proper fashion?

@1:02:55 - steven.ayers

I mean, a dashboard and a theme, though, aren't really the same thing, right? Like. I would assume there'd be some sort of dashboard at some point, but.

@1:03:06 - JD Leonard

Yeah, there is a UI, right, for CRM, and the question, like Steve's proposing, or basically saying, like, there can be a different theme that is surfaced, right, to the user when they are navigating CRM things, CRM pages.

ACTION ITEM: Add default image/photo field to Contact types; use type icon as placeholder - WATCH

@1:03:29 - steven.ayers

Oh. Anyone have thoughts about the image or the photo field? Okay. I do.

@1:03:40 - JD Leonard

I think it's a very high, there's going be very high demand for that, and I think it makes a lot of sense to have it, and to have it in one place that everybody understands where it is, so that it can be leveraged by other things.

@1:03:53 - estevenson

So, just so I'm clear, this is related to what's on the contact page. I I do. I

@1:04:08 - steven.ayers

Yeah, this would be so that contact types would have like an icon or a photo that would just be like a default.

And then each contact itself would have the option to have an individual photo or logo uploaded. But if failing one, you can use the image from the contact type as a placeholder.

@1:04:30 - Scott Wolpow

Or you can do like most places do, just use the first letter or the initials of the person or the contact.

@1:04:41 - steven.ayers

I mean, I'm not that talented, though, so.

@1:04:46 - JD Leonard

I actually wonder if that's something that, you know, could be almost superimposed on top of the logo or something and some sort of visual treatment.

So you kind of get the best of both worlds.

@1:05:05 - steven.ayers

I assume everybody's super excited about ethnicity and super glad I included it and think the choices there are the perfect ones and there couldn't possibly be anyone who disagrees.

@1:05:19 - James Shields

I mean, what were the choices for ethnicity?

@1:05:24 - JD Leonard

Steve and not Steve. I need to not make jokes.

@1:05:28 - steven.ayers

I need So, the web form module provides a number of demographics, and so these are the ones that they provide.

So these would be the ones I'd be proposing. But in order, it won't be included on any contacts by default.

The site builder has to go in and add this field to the people. this field people. go in The Thank

And they would then be presented with the list of options that they would then have to at least tacitly accept by continuing, right?

@1:06:10 - estevenson

You have the option prefer not to say, because I know that that is often requested.

@1:06:19 - steven.ayers

Well, it's not listed here. And my thoughts were that the default would not be required. But, I mean, there are cases where it would be required.

@1:06:32 - JD Leonard

But if I could, I could cite some U.S.

@1:06:34 - steven.ayers

law that's super amazing.

@1:06:38 - Scott Wolpow

If you're a government contractor, you have to ask these. And if you're a veteran, if you're disabled, and so forth.

@1:06:46 - JD Leonard

But what I'm thinking, what I think Eric is getting at is there's a different concept between we don't have any data, we haven't collected the data, versus we have collected somebody who has positively said, I prefer.

Yeah, I mean, I see that.

@1:07:04 - steven.ayers

I'm trying to pull up which one was it. All right, . actually has like an ISO standard associated with it, so that's...

I feel a little bit more comfortable going with these than if just going with what Webform was going with in terms of...

@1:07:22 - estevenson

Mm-hmm. Though I know kind of that... Yeah, pretty much there is unknown, and then kind of like, I prefer not to share this information, which is sort of slightly different, and you know, kind of like...

@1:07:36 - steven.ayers

It is slightly different than whether it's required, so...

@1:07:40 - estevenson

Yeah, like I remember when I was going through kind of, yeah, kind of employment states, that that was a very, very common field, in addition to everything else, just because, yeah, sort of prefer not to say was valuable, because like it also, if you were trying to...

So pretty much if you were trying to figure out, are people willing to share information with you? And they said, prefer not to say, then that is information that, oh, kind of something about our process is making people not want to say it versus they can't be bothered.

Sure.

@1:08:18 - steven.ayers

I mean, I see that it's a valid scenario. It's just... Yeah, sorry.

@1:08:24 - estevenson

It wasn't part of the ISO standard.

@1:08:26 - steven.ayers

Yeah, we don't need to belabor it.

@1:08:28 - estevenson

Apologies.

@1:08:31 - steven.ayers

I don't really know, like, what the correct choices for any of these should be, or if they should even be included.

I did go through and look at different CRMs and see what different demographics fields they have. And, I mean, these are the fields.

@1:08:52 - James Shields

I'm not sure if it's a demographic or not, but have we got preferred pronouns?

@1:09:00 - steven.ayers

No, no, we don't. I am sure that was somewhere in some CRM, but I did not make a count of it.

@1:09:16 - Scott Wolpow

Doesn't that just be a text field at this point?

@1:09:20 - steven.ayers

Yeah, like a list text field. That's what all of these basically are, right? Just a list field.

@1:09:28 - estevenson

Well, yeah, no, but like having the standard available, just sort of like for emails that this person prefers to be referred to as she, her versus he, him is helpful.

@1:09:42 - steven.ayers

Yeah, no, I'm not saying not to have it. I'm just saying I didn't include it. There was another one I didn't include that I, I can't remember.

Oh, nationality.

@1:09:59 - estevenson

Um, it's,

@1:10:00 - steven.ayers

Different than ethnicity, there are a finite list of nationalities, which is basically citizenship status, right? You can be a U.S.

citizen, but if you're from America, Samoa, you're not a citizen, you're a U.S. national.

@1:10:19 - Scott Wolpow

But can't they just add those fields by themselves?

@1:10:23 - steven.ayers

They could, and they're not included on anything by default. So they still, in order to use these fields, you still have to add them to the contact type.

Right. But in terms of what they would be named, if you do it through the UI, they're going to be prefixed with field underscore.

And for some of these, there is actually like a correct list. Like gender, you're not going to find a definitive list.

But there are only so many countries in the world, there are only so many citizenships. Right. I'm not saying that that's one that has

That's going be added, but like right there's height and weight, right? You can be a certain height and you can be a certain weight.

That one may not be as good of one. It would require, we're not going to add dependencies. So if we use that physical module to provide height and weight fields, you would have to choose to install that module separately.

It wouldn't be downloaded and installed by default.

@1:11:31 - JD Leonard

Yeah, documentation is going to be key to unlocking a lot of this stuff.

@1:11:37 - steven.ayers

But it gives them base fields with the appropriate names and anyone who wants to build on top of this would then have access to, like right, I don't know recipes inside and out, but I'm fairly confident that member platform can choose to have their own genders or whatnot that are different from this list with a recipe.

Thank Thank

@1:12:00 - JD Leonard

Yeah, a recipe can basically say we have these dependencies that are going to be installed, and we're going to apply some changes to configuration, for example, updating a list, any of these, you know, list of options to have whatever we want.

@1:12:21 - steven.ayers

But yeah, take a look through the different demographics, and we'll discuss them more in depth in two weeks is my thought.

@1:12:30 - JD Leonard

Nationality is an interesting one, because you can have more than one nationality.

@1:12:36 - steven.ayers

Did you take the citizenship oath?

@1:12:42 - JD Leonard

I was born in the U.S., so I didn't have to take an oath here, and I was naturalized as a British citizen when I was a minor, so I think my parents signed something on my behalf.

Hmm. Why'd you ask?

@1:13:00 - steven.ayers

Well, okay, Erica, I'm going to, I don't want to pick on you, but I want to ask you two questions.

@1:13:06 - estevenson

Okay. have to answer either one of them.

@1:13:08 - steven.ayers

Okay.

@1:13:09 - estevenson

It's a Canadian test.

@1:13:10 - steven.ayers

How Canadian are you?

@1:13:11 - estevenson

I ask you, how much do you weigh?

@1:13:13 - steven.ayers

And you tell me in pounds. I then ask you how much you weigh at the doctors and you tell me in kilograms.

@1:13:18 - estevenson

Mm-hmm.

@1:13:20 - steven.ayers

So, JD, if you were a British citizen and you took a citizenship oath in the U.S., you would have to renounce all foreign monarchs.

So the question is, where would that sit with you in relation to the Queen of England?

@1:13:36 - estevenson

I mean, I know kind of someone who kind of was born Canadian and then gained an American citizenship through military service.

Without having to renounce his Canadian sort of citizenship. And I could imagine kind of like a third thing where like if that person was native or sort of aboriginal.

They might have kind of their aboriginal kind of like status. So then you could have kind of three nationalities.

I mean, I agree that you might put these inside different fields, but, and yeah, kind of, there's an upper practical limit that I don't think you could beat like five, but.

No, there are like only like so many recognized national, like citizenships though.

@1:14:21 - steven.ayers

Like on a passport is what I'm thinking. Yeah, that, um, and you can have it be a multi-value field if you want it to, right?

You can just change that in the config.

@1:14:34 - JD Leonard

Oh, you can change that when you add, add the instance of it, huh?

@1:14:43 - Scott Wolpow

So, so we're not akin to that, but let's say in the CRM, we want to add such things as our four-legged family members, our fur babies.

@1:14:51 - steven.ayers

Yep. How would we put that in the system? You'd want to create a new contact type, just like you would a new content type.

Whether you want to choose to add it as, say, a cat or just as a general pet is probably your call and, you know, what your use case is.

you're a veterinary clinic, you probably want to classify each animal differently because cats and dogs have four legs, but parrots only have two, right?

All right.

@1:15:26 - estevenson

Well, mean, functionally, you just sort of more care about them as patients, that, know, kind of like as a patient, maybe you care about the type, but functionally, yeah, kind of ward would be sort of the general one, I guess.

@1:15:42 - JD Leonard

I mean, this example of whether you choose to add a contact type of pet or a contact type of dog and a contact type of cat, etc., right, goes back to the same question about, well, if you want to have different types of people that you're kind of considering in some way.

I think that should be a subtype, and I know you don't like that idea. No, no, no, no. I don't know that I don't like that idea, but what is a subtype?

How does that get implemented?

@1:16:18 - steven.ayers

We've had a previous conversation about this. Oh, yes.

@1:16:22 - JD Leonard

Oh, here it is. Sorry about that.

@1:16:37 - steven.ayers

So, you might have different categories of people, but they are still people. You would not want them to be two separate entities.

For example, a student could also be an employee, or a customer could also be an employee. And, right, you don't want to duplicate your data.

And they're kind of... And the same address and they're going to have the same phone number. So, right. But they might have some additional fields that the other ones wouldn't have.

So like, if you're not a student, having a student ID doesn't really make sense. But if you're not a student and it's blank, then do you really have a student ID?

So you would be able to add, say, student ID field to the person contact. And there would be something that would be a multi-select value field for your subtype.

Where, I guess, the subtype would then be a config entity. And you could control what additional fields are shown or hidden in the form and UI.

@1:17:46 - Scott Wolpow

A lot of things. So let's say you're a union member. You'd have to fill out your union card number.

Make that required. Are we using web forms to do this? Own set of forms.

@1:18:01 - steven.ayers

It would be our own forms. Okay. I'm pretty sure web form can integrate with entities, but I haven't done it frequently enough to speak authoritatively on it.

@1:18:14 - JD Leonard

Now, the specific example, though, of a union member, that sounds like it might be a field associated with the membership or a relationship between that person and the union, right?

@1:18:27 - steven.ayers

Yeah, so I didn't want to talk about any more computed fields or relationships because that's kind of like painful, but if there is a way to add fields to contacts that are really just data on relationships, it's possible it could be done with a computed field, but what's the real advantage there?

It's not going to be part of the data model, so when you go to query it, you can't, so let's take the relationship.

Questionship entity as an example. When you do entity query, you have to query contacts, plural, not contact underscore A or contact underscore B.

Those only exist in the fields in terms of like a form and the display. I think maybe also with views, but not with entity queries, right?

There's not a database table that corresponds to contact underscore A.

@1:19:30 - JD Leonard

I believe an entity field query, you can specify the delta. You can.

@1:19:35 - steven.ayers

I mean, there are ways to do it. I'm just saying contact underscore A is not a valid property to do a query.

@1:19:44 - Scott Wolpow

So, because I know a lot about the unions, I manage a couple of union websites, and this thing called the book.

And then the book is where someone does know, you go, you sign up, and let's say you're working at an IBW, and you've been unemployed for six months.

Once you're higher up in the next allotment of being no-told about a new job in your area, and if you just finish working, you drop to the bottom of the list.

How do we put those rules into the system? Is there a method of doing that? Is that a future we need?

Or is that outside the scope of the project?

@1:20:19 - steven.ayers

Well, in terms of CRM itself, it's like an ecosystem of stuff. So CRM by itself doesn't really accomplish anything.

It's like a fancy address book. Okay. But in your particular scenario, right, they're working at Job Site A, right, which is some relationship to the union in some way.

@1:20:43 - Scott Wolpow

Right.

@1:20:44 - steven.ayers

So I would think it would either be the employment relationship or maybe a new relationship type you would use for that.

Each relationship has a start and end date, right? So you would start working on a job site and you would end at a particular time.

And the more I'm... Talking about it, the more it sounds like you probably want it to be a separate relationship type than employment, just because, I mean, they're similar, so I don't know, but.

It's a work assignment.

@1:21:11 - Scott Wolpow

They don't get assigned, but like, in this case, you have two relationships. You're a member of the local, and you're working for a contractor.

And you work for X amount of times. It seems like Erica is familiar with the unions also, because you're not in agreement.

So I'm trying to see where we put that in, or such as other things. I'm going be building a directory where people claim profiles.

Is that part of CRM? Is it part of member platform? Or is that something in a different area?

@1:21:52 - steven.ayers

I'm not sure.

@1:21:53 - JD Leonard

So CRM, you would have an organization contact. For each organization that you want people to be able to claim, right?

You would have a contact of type person for each person that you want to represent in the system. A given person may or may not have a user associated with that person who can log in, right, and do things.

And they inherit permissions potentially based on the relationships between their associated contact and other contacts. So that's kind of the broad framework, right, for what CRM provides.

When it comes to doing something very specific, right, CRM is not going to provide very specific functionality out of the box.

But hopefully what you're describing is something that can be represented by the things that are there.

@1:22:55 - Scott Wolpow

So CRM is kind of like just a Lego brick base starting.

@1:23:07 - JD Leonard

Yeah, think it's not about pulling the data from CRM, it's about leveraging the data stored in the content, you know, in the data types, the entity types provided by CRM.

So I don't think the CRM is not going to itself, you know, the base module provide an ability to claim profiles.

Profiles, exactly, or claim organizations. fine.

@1:23:33 - Scott Wolpow

So do I make that as a CRM add-on module? Do I make that as a separate module or as a member platform?

I don't where to put that in the system.

@1:23:45 - JD Leonard

Yes, it's probably you create a project in the CRM ecosystem, you know, CRM, I don't organization claim or something like that.

I don't know exactly what the requirement is. So go click.

@1:24:00 - Scott Wolpow

CRM claiming, if you load the module, dependency, of course, will be CRM.

@1:24:06 - JD Leonard

Sorry, I missed that last part.

@1:24:08 - Scott Wolpow

If I make a module called CRM claiming, if you load that module, you couldn't load that and not enable that until you had CRM, because it relies on CRM to do it.

@1:24:20 - JD Leonard

Sure, yeah, you can create a custom module that has CRM as a dependency, and then can leverage and knows about the things that CRM has, right, and doesn't have to do all the legwork, just has to do the legwork specific to the functionality that that module is trying to provide.

@1:24:38 - Scott Wolpow

And would that be part of the CRM ecosystem or the member platform ecosystem?

@1:24:44 - JD Leonard

So my philosophy on this is member platform is a community initiative, and there will be some things that are sort of very specific to member platform as an opinionated sort of...

Use of CRM, but that anything that could be useful to organizations that are leveraging CRM, but are not necessarily leveraging member platform, should belong in the CRM ecosystem sort of namespace.

But if the thing you're providing is sort of dependent on the assumptions and things that are specific to member platform, then it makes sense to be, you know, in member platform space.

And sometimes you might create a CRM namespace module, and you might also create a member platform namespace module that builds upon that and, you know, has the additional assumptions and, you know, benefits of member platform.

@1:25:43 - Scott Wolpow

Got it. Of course, member platform has no code.

@1:25:48 - JD Leonard

There's nothing to depend on right now. Right? But that is in a large part because so much of the functionality, right, is not specific.

Two-member platform, right? We haven't really gotten to that part of the functionality yet outside of planning. So speaking of other modules in the CRM ecosystem, we've been talking about CRM event and how to represent an event in the CRM ecosystem and things like that.

James was looking at how to adapt the entity registration module to sort of serve our needs, to have contacts as registrants for an event as opposed to users as registrants for an event.

And Eric has been working on a spec for CRM event. So maybe, James, do you want to go first and talk a little bit about what you found and pull the group here?

Hey.

@1:26:59 - James Shields

Hey. Sure. So I haven't got into a huge amount of detail yet, but I was looking at the entities in the entity registration module, and it creates a registration entity.

And, yeah, it took me a little while to fully grasp that the entity in entity registration is the entity that you're registering, such as an event or, so it's kind of what you're registering to, not what's registering.

So, and it kind of assumes that it has an author, I think it's called, on the registration, which is the person who did the registering, and that has to be a Drupal user.

But then the actual registrant... It stores the email address within the registration entity. So I think it doesn't really assume that it's the Drupal user that's in the author field.

So we would want to try and link that to a contact in CRM or possibly a member, if we get the member part of it.

So we could possibly do that by adding a field onto the registration object or maybe create a child module or a relation module with a link field.

So I'm sort of still kind of exploring that. But... But... ... ... ... ... ... That's sort of my feelings so far.

And I don't know whether we'd be better off trying to do it by extending the entity registration module itself or by adding an additional module to all the additional information.

I'm sure both have pros and cons.

@1:29:30 - JD Leonard

I haven't looked at it too deeply, but my gut reaction is that while it might be easier in some ways to just sort of bolt on the additional information, the entity registration module has a base assumption that a user is the registrant.

And if we don't address that base assumption, then we're kind of, you know, sort of a second class citizen, bring back nationality into the...

... Not exactly nationality, but maybe it's an opportunity for entity registration to support, in the same way that it supports any entity type as the thing that is being registered for, perhaps it could support any entity type as the thing that is registering.

But I don't, I don't know what other assumptions it makes or, you know, dependencies it has on the core concept that the user is the thing that is registering.

But of course, that would be a major version increment, right, for the entity registration module.

@1:30:45 - James Shields

Yeah.

@1:30:45 - JD Leonard

But it would be a pretty amazing thing to contribute, you know, back to that, that ecosystem.

@1:30:51 - Scott Wolpow

So the entity registration module, that's to register on the site or that's to register for events? Okay.

@1:31:01 - JD Leonard

Actually, that was a question I was wondering myself.

@1:31:03 - James Shields

I think it could be, it could potentially be either or both.

@1:31:08 - JD Leonard

Entity registration, the concept of it right now is you can create an endy of any type, right? So you might create an endy of type event, right, to represent an event.

And then you configure different registration types, and you can basically configure for a given event which registration types are valid.

And then you can say user, right, can navigate to the page for the event and can register themselves, right, for that event.

It supports additional things like, I think, plus ones or I don't know, I don't remember exactly what it supports, right?

And it's all fieldable, right? So you can, for each registration type, add whatever custom fields you want to collect, like T-shirt size or...

Or, you know, whatever it is you need to, information you need to collect. There's also another project that integrates ND registration with Drupal Commerce to support paid registrations for events, which is pretty powerful.

And so it'd be great for us to be able to leverage that, right? And not have to build a lot of that sort of complex integration if it already exists.

@1:32:26 - James Shields

So, but yeah, but just to add to that, you, I mean, we could, so you were talking about events there.

So we're obviously going to have in the meetup.com situation, you'd be talking about registering for events that your member organization is organizing.

But you could potentially also use it for joining the organization itself.

@1:32:58 - JD Leonard

Well, you're saying the organization. I think you just mean an organization in general. I do mean an organization, but yeah, but I mean...

opposed to the organization in the member platform sense of like there's an organization for this website.

@1:33:12 - James Shields

So I'm thinking of, you know, that you have your, you know, that I have a Lego association. You have your residence association that a new person wants to join that association that could potentially be done through entity registration.

@1:33:41 - JD Leonard

But yeah, entity registration could be, could be used to trigger the creation of a membership. Yeah.

@1:33:52 - James Shields

Between a person and an organization.

@1:33:57 - Scott Wolpow

So why, why can't we just... Let's in the fields and we're configuring the CRM into the entity registration.

@1:34:11 - JD Leonard

So the trick right now is entity registration makes the assumption that the thing that is being registered is a user.

But CRM, our big, one of the big novelties, right, of CRM is that we are dealing in contacts, not users, right?

A contact doesn't necessarily have a user that logs in as that contact, right? You can represent people that don't have an account in the system.

So we kind of need to overcome that limitation of entity registration, right, for us to say a contact can register as, register for an event or register for, to be a member of an organization or whatever it might do.

You use entity register.

@1:35:00 - Scott Wolpow

Registration, do you need to be logged in to use it? Is what you're saying?

@1:35:06 - JD Leonard

I don't believe you need to be logged in to use entity registration, but I don't know. I haven't installed it in many years.

@1:35:13 - Scott Wolpow

So if you're on the front end as a, you know, a drive-by user and you're registering for events, just like you would at any other events, unless they require you to register on the CRM side, it's still basic information.

So that thing, you're not really registering as that use. Because what you were saying to me, looks like misunderstood, if you register for an event using entity registration, it logs you as the person you're logged as a Drupal user, not as an unauthorized user.

@1:35:50 - JD Leonard

Yes, when I said I don't think you have to be logged in, I mean, I think you could use entity registration in such a way that it effectively creates a user account in the process.

But any registration requires that the registrant be a user.

@1:36:08 - Scott Wolpow

And I'm assuming if we're doing event registration or CRM, they'd be logged in anyhow.

@1:36:18 - JD Leonard

I don't think we need to get too caught up on whether or not you're logged in. It's really about the data that's being represented under the hood, right?

The user experience has to come as well and be thought through. But ultimately, it's like, what is the thing that is registering, right?

Right now, any registration says it has to be a user. But we are not dealing with users. We are dealing with contacts.

@1:36:43 - Scott Wolpow

So in most cases, the user has to be logged in. Otherwise, you don't know who they really are. It's just a person filling out a form.

@1:36:54 - estevenson

So, like, one scenario that we touched on earlier, like people having pets. of the Thank That I am a doggy daycare, you know, kind of like I have like a potential event for cats that we've got kind of some type of vaccination and, you know, kind of we want to track kind of that the cats came to this vaccination or they didn't.

The cat obviously is not going to register itself for the event. It's going to be the owner. And you could have a scenario where kind of they have an old cat and the person doesn't want to risk it, but they have a young cat.

So that person might have kind of like contacts, like you'll where each pet is contact, where one has attended the event and the other hasn't, but both contacts trace back to the same user who is their owner.

So kind of like that's the sort of scenario. So yes, as part of registration, there is a user, but they are registering their pets to an event, you know, kind of on the pet's behalf.

Does Does that make sense as just sort of a use case where you'd have a disconnect between who's logged in and who gets sort of registered to the event?

@1:38:11 - JD Leonard

Or another example is an executive assistant registering their boss for an event, right? The actor or the person who's taking the action is the executive assistant, but the person being registered is the boss.

Each of them would be represented in the CRM as a contact. Maybe the boss doesn't have a user account associated with their contact, but the executive assistant has a user account associated with the contact and has permission to register their boss.

@1:38:45 - Scott Wolpow

Let's go across permissions where a designated person would have permission to do certain functions in the CRM. Based on the CRM, even though they might be able to have permission to register their boss, they can't change the boss.

Contact, or maybe they can, but they can't do other things. So again, that would, because I've been investigating it, so that would be a cross-relationship between two groups.

I'm assuming in this case the CRM is one group. Let's keep it simple. So say in this group, this person would have a configuration field of items they can do based on the modules installed or the functions installed.

This person can do these permissions. So it'd like a mini ACL within that CRM.

@1:39:38 - JD Leonard

Yeah, so, you know, one could develop any sort of access control system based on the things that CRM has, right?

But the sort of general assumption, right, is permissions are likely to be derived from relationships between contacts. Contact, or maybe they can, but they can't do other things.

So again, that would, because I've been investigating it, so that would be a cross-relationship between two groups. I'm assuming in this case the CRM is one group.

Let's keep it simple. So say in this group, this person would have a configuration field of items they can do based on the modules installed or the functions installed.

This person can do these permissions. So it'd like a mini ACL within that CRM. Yeah, so, you know, one could develop any sort of access control system based on the things that CRM has, right?

@1:40:49 - Scott Wolpow

But the sort of general assumption, right, is permissions are likely to be derived from relationships between contacts. Contacts plus the association between a contact and the user account representing the same person as that contact, if one exists.

@1:41:14 - JD Leonard

Right, so if I have a relationship with my boss, right, that, you know, basically gives me, delegates control over my boss's contact to me, right, then maybe I can, as the executive assistant, log in as the user associated with my contact, right, and modify not just my own profile and information, but that of my boss.

And register, not just myself for an event, but also my boss.

@1:41:45 - Scott Wolpow

So that begs the question I asked earlier, the same thing, does that go into the base CRM module, or is that the CRM group ACL module?

And I know there's a right or wrong answer.

@1:42:05 - JD Leonard

I don't think there's an answer right now. I think the organizations are going to have diverse requirements as it relates to their access control needs.

And CRM, I think, will provide some framework, right, for that access control to be figured out.

@1:42:29 - Scott Wolpow

Right, but it's unlikely to provide out-of-the-box kind of, you know, point-and-click to get exactly what you're looking for.

@1:42:46 - JD Leonard

My personal preference is keep the base module as simple as possible, not to confuse people, and have everything as add-ons as you need it.

@1:42:56 - James Shields

Kind of a little bit out of the JoomlaSys ecosystem. you. You You You You Without the mistakes they made.

I think that is the general approach here, is to keep CRM simple, small, minimal dependencies, make it easy to maintain, right?

And then allow the ecosystem to build around it to provide more complicated, more interesting functionality than, as Steve puts it, a glorified address book.

@1:43:25 - JD Leonard

Maybe that's how I put it. I agree, that's a great way of starting. call it a citation. You know, the real basic, most minimal information to start out with, and build from there.

So, James, going back to entity registration, what do you think the next steps are here for us to take this adoption forward?

ACTION ITEM: Investigate Entity Registration for CRM Event Registration; document OOTB; propose contact-as-registrant plan - WATCH

@1:43:59 - estevenson

Good question. I'd like to do a bit more tinkering with it, and I don't really have a definitive answer at the moment, so I'm happy to tinker with it some more and maybe try and have a better answer next time we meet.

SCREEN SHARING: Estevenson started screen sharing - WATCH

Sounds good. Anybody else want to dive into the entity registration internals and figure out? A possible plan? All right.

Next up, Erica, do you want to talk a little bit about the CRM event spec work that you've been doing and, you know, if there's any call to action you have for people here or questions?

Sure. I mean, kind of mostly at this point, it would be in terms of call to action just to review it.

Um, just a sec. I'm going to see if I can... And sort of share screen as soon as I remember.

There we go. Okay, I'm just going to share that. And then I am just going to go. So just within the member platform, I've added this new document, CRM events spec, that I'm still working through.

I didn't, I tried to get to kind of reusable venues, and then I found like other holes inside the document, which I'm working on those.

So it is still inside process, but this is just sort of, we've been talking a whole lot about the how.

And this document is trying to define the what in terms of kind of events. And I would argue that this is even, like, we're not even talking about specific modules at this point, because, you know, kind of, we might, you know, as discussed, just take, you know, the sort of entity register.

And that becomes kind of CRM event registration. But yes, just sort of conceptually separating it out into two different kind of core responsibilities.

So kind of, and this is also just sort of to discuss to see if I have missed anything as I've tried to sort of label stuff out.

Um, so just to sort of first define kind of CRM event where we'd want to define what an event looks like.

And I've got that down below, um, deal with the credit operations for events. Um, it would be in charge of the listing and calendar views, um, which, you know, kind of, yeah.

Yeah, um, one new concept, what, you know, kind of sort of been talked about inside other documents that we sort of want to provide as a starting point that's a little bit outside of kind of the absolute default would be a reusable venue.

So people would be able to save address details that, you know, kind of Clubhouse A, so that then you'd be able to do a lookup kind of inside the sheet, sort of like when creating event and just do sort of Clubhouse A and it would autofill the details, which, yes, I need to sort of spec out.

But in terms of functionality that, you know, we would be going for, for CRM event, which could be a different module.

Yeah, no, and then a fair amount of it is a little bit what we were talking about. What are the default sort of user permissions for CRUD operations?

So, yeah, like, I mean, out of the box for version one, are we going to worry about kind of I am a pet owner and I want to register my pets?

Or sort of more within the existing functionality of sort of what we have for CRM that I am a head of a household and I want to be able to register my household members.

Um, so that needs to be defined, and I would argue that's part of CRM event. And then CRM event registration, which, um, yeah, that would effectively be what we're talking about for NT registration.

Um, so, yes, without getting prescriptive, this is what we'd want it to do. Um, so, yeah, one define it, one NT relationship, a.k.a.

however we do it, the relationship between a content and an event, as described inside that first sort of functionality bundle, um, you know, kind of allow users to set and change on these event registrations, define future flexibility.

Um, so, yeah, like, we want to kind of set a limit for the start that we want to be able to accommodate X, Y, Z, um, while kind of keeping in mind that we might, we want to sort of have room for other things.

Um, allow business rules around registrations, aka allow users to limit how many can register an event, um, possibility for future rules, um, like I think the number of rules that we'd have at the start might just be limit the number of users, but again, just sort of like thinking how we design that, um, handle what happens when a contact is deleted to respect privacy laws, um, that, you know, kind of, yeah, I sort of ended up adding that, but that's something that even if it's arguably just part of the CRUD operations that you'd sort of assume would be default, that's one that requires sort of definite things, I've kind of included events and registration, um, just because, yeah, we're definitely going to be referencing that, but like I said, this is going to be focused on the what instead of the how, um, so now kind of, like I said, defining what

An event should be. Yeah, I partially kind of was able to find kind of an old sort of Drupal site that was for like 6x, but, you know, kind of that at least provides sort of something to, basically something to an objective truth.

So, stole some of it from that. So, an event would consist of a title, a start date and time, an event location, which sort of like I sort of started to spec out, description and date and time, event status, my kind of proposed statuses, which again, this is one that totally needs sort of debate and feedback.

That's what this document is for. Yeah, kind of upcoming registration open, upcoming registration code, upcoming drop-in, passed, canceled. No, and then, yes, here I was starting to spec out func

That obviously event management, however it does it. And this, kind of is largely stolen from kind of a different thing where I've got the link.

So, yes, we've got the CRUD. We've got the event listings. I know one thing I took out of this was listing RSVP members because, yes, as part of the event module, it would not be responsible for RSVP models.

It would be the second one that's responsible for going back to this to add it. And then, yeah, permissions, which is a bit of a sinkhole, as we were sort of debating, that of the possibilities, again, focusing on what member platform needs in order to get to beta, what are the permissions we need to define?

So, yeah, view event, an event can be seen by anyone, can see by registered members, potential future scope, an event.

Can be seen if member status is X, can be seeded if associated has does not have tag X. Yeah, same thing, create events, and I'm just going to be going on about that.

This is one that we'd probably possibly go section by section to debate or leave it for a future meeting.

Um, then yes, CRM event registration overview where a CRM event registration, um, you know, kind of for functional minimum would have to reference an event after the attending contact.

@1:52:37 - JD Leonard

And then one that might be important because I realized it could be a little bit of sort of a rabbit hole is reference to the last user or contact who changed an RSVP that like I sort of said inside a contact and said sort of the comment on the side that what happens if you have someone who kind of.

Inside the system is initially a parent or something. They register for an event and then something happens, like there's been child abuse and now that person's off that, they're the other parent.

And then kind of the event comes up and the person doesn't show and then they kind of ask how that happened.

@1:53:18 - Scott Wolpow

And logically, if we're going to have people who, if you're going to have the ability for someone to register a contact who they themselves are not, we're going to have to have some type of auditing system.

And I think maybe that's just as simple as having user, you know, kind of like every time a user changes it, it has to sort of be there and then the event log would sort of capture that.

So for that one, certainly the sort of obvious answer would be that an event registration entity could be revisionable, right?

And each... Revision, right, would correspond to a change that was made and can, you know, reference the user that made the change.

Okay. Scott, you're muted. Scott, you're muted. Scott, you're muted. We can't hear you. Sorry. One thing that's important to have is a critical path.

So I have a kayak group that I run, and our sister group is a rowboat group. And we have different waivers because of the insurance rules.

And so you can't go on either trip without signing the waiver.

@1:54:33 - estevenson

One waiver you can sign for the rowboats at any time is good for the season, while the kayaks have been signed the day of the event.

And we'd love to be able to publish a list to see who signed up, who signed the waiver up so we know about it before they get there.

The other part is, let's say we were limited to 12 people, but we can allow more than 12 so we can pick through who we want on the trip.

Based on other criteria, and lastly, as you're on the bottom, do they need to register as a Drupal, as a Drupal user for the entire system and put them into a group, or would that group be just that event, or how are we going to do that?

@1:55:17 - Scott Wolpow

And that means that every time we create a new event, we'll be going to be another group, because, you know, you may want to isolate them to only build to register for certain events based on whatever criteria the siteholder has.

Yeah, no, that's touching into kind of permission. Ah, you were down to the bottom, sorry. All right. Yeah, so kind of like for potential future scope that, yeah, can only create RSVP for certain types of events, that, know, kind of like, yeah, based on if you are this type or that type, or like, that one kind of applies to all the following ones.

But yes, you're sort of saying that, you know, kind of, okay, so how would you change the, you know, kind of potential future scope to account for your use case?

Could you run it by me again?

@1:56:13 - estevenson

Well, I'm just being devil's advocate to some extent. So let's say we have the circumnavigation around Manhattan Island, which is one of events we do.

Would that be under all members of the Drupal site? Would that only be members of that event that we invite to it?

Because we only invite volunteers who have done X amounts of hours volunteering, whatever rules we have. Or do we have it open to the public?

Are we picking shoes? But we don't want them. Let's say we have a private event that was definitely closed.

And we don't want the public to see. How do we control all that? And if they register, if they're brand new, do they see all the events?

And that gets, again, it gets to a complicated ACL. Do we need, how do we, do we, do we implement this into the event system?

Was that in addition, would that be CRM events, ACL? So, yeah, kind of one thing about this particular document is it's not prescribing the how.

It's just sort of like, of the scenarios, kind of like, which ones do we want to potentially, you know, kind of like accommodate and which ones are we going to accommodate this time?

So inside this case, yeah, kind of. So in terms of how would we do this, that's not what we're trying to define here.

It's just sort of like, is there a use case that, you know, kind of we either are or plan to accommodate and just recording it here so that then when we're doing that implementation, we can refer to this and then just sort of like, oh, that, um...

Just sort of capture it so it's not just sort of floating. Oh, it doesn't accommodate this. So for your example, kind of like we only want, yeah, kind of we only want people who have accomplished X.

One way that you could do it is that, you know, kind of once people have accomplished X, you have some type of rule that assigns tag Y to kind of that sort of like contact.

And yeah, kind of like, and then you have a rule that if the person has tag Y, they can see the event or they can or can't register.

So, yes, you might have a newbie tag for sort of people who do that and then it sort of gets removed.

Or you might have kind of an experience tag that gets sort of a sign that after you have attended X sort of events, you have some type of trigger that fires.

@1:59:00 - JD Leonard

And starts applying that tag. So that's how I imagine you would accommodate that. But yeah, a lot of this is, yeah, trying to figure out just ahead of time what scenarios we want.

Does that make sense? Yes. So I'm not going to get off the call in four minutes because I have another session summing up.

So thank you. Is this posted anywhere? This is posted inside the member platform.

@1:59:30 - Scott Wolpow

Yeah, so no, so it is just, I'm still going to sort of make some more changes to it because I need to sort of detail out reusable venues.

But it is, yeah, a place for figuring out, have we overlooked something? And then, yes, as this sort of matures, then it would be, yeah, then we'd be moving on to discussing the how.

This is just the what.

@1:59:58 - estevenson

But what Erica described, right?

@1:59:59 - James Shields

let's time. you.

@2:00:00 - JD Leonard

As like the tagging concept, I think it's very powerful because Scott, would allow you to basically manage whatever logic you need, right?

That's specific to your use case to say which contacts can register for an event.

@2:00:14 - James Shields

You could just create a tag and assign it to whatever contacts, right? It should be registered to whatever logic or automation you choose to implement.

@2:00:21 - Scott Wolpow

And then CRM event registration would, the theory would be support configuration per event to say, you have to have this tag in order to register.

@2:00:32 - JD Leonard

Sounds good. Everyone, there's a great meeting. I'm really psyched for this.

@2:00:40 - estevenson

I'm going try and get into some stuff, although my time is pretty packed, but I'll squeeze it in somewhere.

Thanks for being here, Scott. And remember, if we do this for cats, it's not a contact relationship management. becomes a cat relationship management.

So... ... ... ... ... Sounds like there should be a CRM pet module that provides an out-of-the-box pet contact type with, you know, the different subtypes for each.

I will have that probably by the summer. Okay, I'm have to go to. My website, arfmeow.com. And yes, Meow Arf will also work.

Everyone, have a good day. Have a good day. Bye-bye. Take care. Good stuff, Erica. What are you feeling about next steps?

Oh, kind of. Well, I mean, like, one, I need to get down reusable venues. But yeah, kind of for me, next steps would be have the group sort of review this and have I adequately described the what.

Like, it feels a little bit weird to focus on that, but it's actually super useful because I

@2:02:00 - JD Leonard

You know, we were quite getting into the weeds and I was getting lost during the discussion. On a personal development level, I might try like registering for DrupalizeMe and just trying to upgrade my skills just because like not knowing.

Well, I mean, on the plus side, not quite knowing what Drupal sort of does means it's a little bit easier to focus on the concept level without getting lost inside the weeds.

But, yeah, that, you know, kind of like I would like to contribute. And while this sort of, this side of kind of implementation is also a little bit unfamiliar to me.

Though I think I've got, yeah, kind of, I'm relatively happy with the summary that I did at the start, which I think is probably the more useful part of the document.

Just, just, just getting consensus on, I don't know, kind of like getting consensus on what we're trying to do.

So what suggestion I have is.

@2:03:00 - estevenson

It's to install entity registration and create an event content type and follow the instructions to be able to have a user register for that event and just see all the configuration options, see what the capabilities are, because my hope is that we can just sort of assume that most of that we inherit.

Those capabilities, right?

@2:03:31 - JD Leonard

And then it's sort of a question of, hey, here is the current state, right, of entity registration capabilities that are relevant, right?

@2:03:42 - estevenson

So like, here's what's sort of there out of the box. And then we can think about the delta beyond that, like, what else do we need?

Right? Obviously, there's the elephant in the room of, well, we have to allow contacts to be registered, right? Yes.

And sort of focusing on that might help so that you're... Not focusing on an event registration system as a whole, but just on the bits that we don't think we're going To some extent, yeah, it is investigating entity registration, seeing what they have, and then potentially like semi-trying to sell it as the path forward.

Because again, some of the goal is to gain consensus and then figure out the how.

@2:04:24 - JD Leonard

Yeah, I mean, I think we can work under the assumption that we're going to use entity registration or something based on entity registration, just because, I mean, it's really fit for purpose for the whole exception of the registrant, right?

ACTION ITEM: Install Entity Registration via JD's recipe; document OOTB; update spec - WATCH

Kind of, yes, we would be reinventing the wheel. No one reinvented the wheel, yeah. Yeah, no, no, no, no, this is very clearly a powerful wheel.

@2:04:49 - estevenson

So, yeah, so if I understand correctly, what would be helpful is, yes, I get entity registration working on my machine, I sort of like detail the functionality.

that it has. I add it to this document in terms of kind of goals.

@2:05:06 - JD Leonard

Just because, yeah, like having that overview that just so it's something that everyone can review because not everyone can kind of have the time to go through the document in detail.

It's exactly the functionality. So summarizing it. I'm going to send you a link here to a recipe that you might try to install.

@2:05:27 - estevenson

Okay, I can do that, given a set of instructions. Yeah, you'll have to go figure out how to apply recipes.

You don't install them, you acquire them. Okay. Yeah. And let's see. If I go to see where the...

@2:05:50 - JD Leonard

But yeah, kind of the one bit of new functionality that I'm pretty sure there isn't going to be an easy thing, an obvious thing for would be reusable.

Thank you. And part of me is tempted to kick that out of kind of version 1.0, but. Sure. And that could be fine.

The only challenge is architecting 1.0 in such a way that sort of supports that concept in the future, you know, without being a barrier to having that concept.

Yeah, like I can imagine how I would do it generically, where, yeah, you have a lookup table, you have a field that allows you to look up, and then it auto fields those fields.

But yeah, kind of, I don't know if that's the proper Drupal way to do it. And I don't actually need to know that, because the more useful thing would be for me to, yeah, go through Entity Module, figure out its functionality, and then just have a summary of that for people to review.

@2:06:53 - estevenson

Yep.

@2:06:55 - JD Leonard

Um, let's see.

@2:07:00 - estevenson

see, what else here, oh, what was Scott talking about with, it was CRM event registration, and I was thinking, like, there should just be a module that extends that, that provides some additional capabilities, I feel it was, oh well.

Sorry. If you scroll to the, like, what an event has, what it consists of. Yes. So just looking at this relative to some of what we sketched out for member platform event detail page and the mock-up notes.

Yes, I've got the mock-up notes here, kind of, because, yeah, like, I was starting to go through it and sort of realizing, yeah, I I left out bits.

@2:07:53 - JD Leonard

Yeah, so I was just wondering if that was with intention, right, like, there. Yes, so kind of, so yeah, like.

I know for venue information, I left that out because pretty much... Fair enough on that. Well, no, because I mean, like, yeah, like, I think functionally, at least until there's a need, that that would just be, here is a space that you can just put text.

And then we've got kind of a little prompt that sort of does that. Sort of, this is what you'd want.

Though I think you might not include that for kind of the default.

@2:08:26 - estevenson

Or like, I mean, kind of those prompts would be part of member platform as opposed to as part of sort of this layer of the project, just because this layer is a bit more generic.

Yeah, no, and kind of like banner and icon, just that's sort of another one that should that be part of the generic or kind of is that something that belongs to, yeah, kind of member platform.

@2:08:53 - JD Leonard

So my initial thought on that is, okay, so this... Then is represented as data in the system, but also I think CRM event should provide a page for the event, right?

That shows the information.

@2:09:11 - estevenson

Yeah. And so by the time you're doing that, well, let me think about that. I guess it strikes me as such a common use case to want to have a visual to go along.

ACTION ITEM: Update CRM Event spec: add banner/icon, format, Internal Notes, views; remove virtual URL; clarify statuses - WATCH

No, I'm, I am okay adding it that, you know, kind of, it was more just sort of, I have to think about it.

Yeah, you were starting from the basics, yeah.

@2:09:37 - JD Leonard

Yeah, so I would go event banner, event icon, because, yeah, no, I would, I would agree that those are pretty standard.

What about summary versus description? I think the concept of summary was. I That it's like a short version of the description, right?

@2:10:03 - estevenson

Yeah, no, that pretty much, this is me sort of stealing this for legitimacy.

@2:10:08 - JD Leonard

Yeah, okay. And I don't actually know if we need to do that, but just within the Drupal documentation on events, it said an event typically contains the minimum set of information or fields, title, start, date, location, description, ending.

But I'm perfectly happy to change it to summary.

@2:10:28 - estevenson

It's more that I just sort of stole this so that, you know, in terms of debate, we can sort of say, well, it's Drupal tradition.

So I'm happy to change this to summary, though, because that is... Well, so we had in Macapnotes, we had two different ones.

We had the description and the summary. And I think the concept there was the description is like all the information, right?

And the summary is a much shorter amount of information that would appear...

@2:10:52 - JD Leonard

Like in a list of events somewhere or in a, you know, on the site somewhere that's... There's a preview of the event.

@2:11:04 - estevenson

Or pitch. Yeah, something like that.

@2:11:09 - JD Leonard

And I don't know, like, I mean, yeah, you could argue that these things are not inherently required to have an event, but then you can not, you can just hide the fields.

@2:11:26 - estevenson

You know what mean? Or not have them. Pretty much. That you don't necessarily need to be prescriptive about it.

@2:11:32 - JD Leonard

Right.

@2:11:34 - estevenson

No, and kind of, like, same thing kind of goes where, yeah, that I sort of did start date time, just because I could point to that.

This is the official Drupal thing.

@2:11:44 - JD Leonard

But, yeah, like, I mean, we could just sort of say the same.

@2:11:48 - estevenson

Yeah, I wouldn't rely too heavily on the link that you saw as being anything official. Like, it's just somebody threw a page together and stuck some information there.

@2:11:56 - JD Leonard

Okay, man. doesn't super matter. Okay.

@2:11:59 - estevenson

Okay. Yeah, yeah, yeah. So then I would just do, I would do event start. So that would be date, start.

@2:12:11 - JD Leonard

So I think we, yeah, we had this stuff already written out. I don't know if there's a, if you're rewriting it differently for a reason or just because you're Yeah, no, so I'm, I'm just then going to get rid of event end date and time and event start.

@2:12:35 - estevenson

And then I am just going to copy this. Just helping you be lazy. Lazy is good. I have no objection to being lazy.

I spent more time thinking about this than I probably should have.

@2:12:58 - JD Leonard

So no, and then this. This is just sort of, again, when it came to stuff like RSVP Limit. Well, that's event registration.

@2:13:08 - estevenson

Yeah, that's sort of why I left it off.

@2:13:11 - JD Leonard

So along the same lines, my devil's advocate in me is saying, I see event statuses here about registration opened or closed, but I guess that's relevant regardless of whether registration is provided on this site, right?

@2:13:25 - estevenson

Yeah, no, mean, like, yeah, that event status was just sort of like, eh. Let's throw something on there that, you know, sort of we hadn't really detailed it.

So I am entirely open that I would agree kind of this is getting, yeah, that it's getting into like, should this belong to the event status kind of bundle of functionality?

You mean the event registration? Event registration, yes, bundle of functionality because. I actually think, I actually think it probably does belong

along here on event, and that event registration could leverage and extend it. Yes. Because even if we are not providing the ability to register on the site, conceptually, an event could have these statuses.

No, you could have an offline thing where kind of people see this, and then they phone them up, and someone does it manually.

@2:14:28 - JD Leonard

And, you know, kind of then it is still conveying useful information.

@2:14:32 - estevenson

Right.

@2:14:33 - JD Leonard

By that same token, maybe it makes sense to add the limit to members only. Add the limit to members only, what are you saying?

Oh, sorry, sorry. So for event, one thing I was trying to figure out, just like you'll kind of...

@2:14:51 - estevenson

So there's add limit.

@2:14:53 - JD Leonard

No, sorry. Sorry, it's the number of members that does the number of...

@2:14:58 - estevenson

The attending limit? It's the number of... Does registrations allowed exist as a rule for event registration, or is it on the event?

Because actually, if I think about that scenario, I want to list my event, and I want people to phone me up and not use your sort of registration thing at all.

Actually, it would be helpful to know kind of this, yeah, kind of this many members are allowed. Like, should that exist as...

I don't think that belongs on event. That sounds like something that would belong on event registration. Okay, that's what I was thinking.

It's something that if you just want to add miscellaneous information about the event, you can always add it to the description, right?

@2:15:39 - JD Leonard

And if it's about tracking registrants for the event, well, that squarely belongs under event registration. Okay, I like this.

@2:15:49 - estevenson

This is what I was thinking before, before I started overthinking it. I've been there. So, RSVPs required optional hidden.

That was sort of... Another one where I just didn't get to it. So I think that one's an easy one to add, but no, that's something that you'd want, that's something you'd want to extend on the event registration bundle of stuff because, yeah, because yes, I mean, if it's just a listing, then that's their job.

And they can just add their own optional field because they're ignoring what we're doing anyway. And I guess organizer events not visible to non-organizers, that's a good one to add.

Wait, what was that one? I missed it. Okay, so this is just one that was on the list that we sort of have this for one thing that that was discussed that for maybe, maybe you want some notes.

@2:17:00 - JD Leonard

That you don't want available to kind of non-organizers, but you want available to organizers that like, you know, kind of, this was registered under Jim's name.

Or kind of, you know, just sort of like, last time we went there, you know, kind of someone had food poisoning.

@2:17:18 - estevenson

We should keep an eye on that. Sure. So that would only make sense with a reusable. Well, no, I guess not.

@2:17:26 - JD Leonard

I guess it could be relevant regardless.

@2:17:29 - estevenson

Yeah, like I would, I would agree that for reusable that I'm happy adding it for kind of, yeah, like, you know, kind of, this, this is where I was sort of debating that, you know, kind of should this, if we don't extend it, if we just make it generically available, then that's one other thing we don't have to extend.

@2:17:56 - JD Leonard

Right. it's just a text field. Right. Yeah. The piece that we would extend in member platform for organizer notes would be around, well, who can see it?

Yeah.

@2:18:10 - estevenson

Right?

@2:18:11 - JD Leonard

Like, we would allow organizers to see it, whereas. So, no, kind of like, this probably goes into permissions, which I started dealing with.

Organizer notes, is it, can, can you organize our notes, can edit organizer notes, is sort of the. So, initial scope can be seen.

@2:18:40 - estevenson

Organizer notes can only be seen by organizers. So, all right, let me insert some Drupalisms here. Okay. might help guide it.

So. Permission in Drupal is whether a user can do something. Yes. And permissions are applied to zero or more roles, right?

So sort of site-wide roles.

@2:19:22 - JD Leonard

So I don't think in CRM event we should necessarily... Well, I don't know. I don't know if we introduced the concept of an organizer or not.

I mean, okay. So let's... To me, what would make sense is if we keep it in and of itself that this is just a posting of an event.

So that, yes, theoretically, I am an organization. I want to do everything manually, but I want to use your sort of thing just so that I can post sort of organizations and use your themes and stuff.

@2:19:58 - estevenson

Under that circumstance... circumstance...

@2:20:00 - JD Leonard

You just wouldn't have organizer notes because, yeah, kind of like you're only doing it. So, yeah, I would agree that.

The version is leave that to member platform. Yes, I like this. And hopefully it doesn't get lost. But then again, member platform has the mock-up notes.

Yeah, yeah, yeah. That's fine. So, and then down at the permissions, right? Yes.

@2:20:28 - estevenson

So really the permission around event is, typically what we would see is something like can view any event would be one permission.

Okay.

@2:20:42 - JD Leonard

then whether that's assigned to anyone or registered users has to do with how the permissions get mapped to roles.

It doesn't have to do with any CRM event. Gotcha.

@2:20:52 - estevenson

And then you might have can view own event.

@2:20:58 - JD Leonard

And then you... you... Yep. You... You... Thank you.

@2:21:01 - estevenson

Although we should talk about that, that in Drupal usually means that you are the user that owns the event.

You are the author, right, of that event.

@2:21:17 - JD Leonard

And I don't know if we want to provide that permission out of the box for CRM event because we're kind of trying to get away from...

Yes, we're trying to keep that bundle of functionality. Like, to some extent, phrasing it the way that NT registration is, where event registration wants to modify something else to allow registration.

@2:21:44 - estevenson

There might be an event permission, can view unpublished events. Okay.

@2:21:56 - JD Leonard

And I don't know if we have a concept of an event being published or not. Okay.

@2:21:59 - estevenson

Thank We currently do not, but we could add it.

@2:22:04 - JD Leonard

So that would mean... think we want that, yeah. Okay, so as part of this, so would that be its own field or would it be a type of event status?

@2:22:19 - estevenson

It would probably be its own. It's probably event status might be where, like the event status might be published or unpublished, and then the event state or something might be these other things that you have listed.

@2:22:35 - JD Leonard

Status. That was not lazy. That would always be overdoing it. But yeah, so event status, and this would be kind of...

That's just published or unpublished. So draft. Oh, draft. Oh, All Is draft different than unpublished? Well, it depends. So usually in Drupal, you have this concept of like, is something published or not?

And that's usually on the status property of the entity or of the content type.

@2:23:19 - estevenson

So yes, unpublished. Because yes, I could see that you have approved this draft, but you only want to publish it, you know, kind of after this date.

@2:23:26 - JD Leonard

So yes, draft can be a separate status that draft is kind of like pre-review. Yeah, it's possible to implement, you know, a publication workflow that has, you know, the event goes through a review process and then this and then that before it gets to be published, right?

@2:23:50 - estevenson

But that's something, that's something that would be more like the event state that you have listed here. Maybe it would be a separate thing and it would influence.

It's whether or not the event is published. Okay, so kind of... You can have a publishing workflow, right? And if you transition to a given state in that workflow, it might then trigger the event status to change to published.

@2:24:19 - JD Leonard

So if we wanted to have draft, it would be kind of event review status or something. Yeah, it's something like that.

So this is the simple version. This is like the obvious sort of out of the box. It's like, hey, is this event published?

Okay. Which then, based on the, you know, can view any event, the implication there is that it's a published event, really.

We don't want to spell that out typically in Drupal, but like, right? And if it's not, the only way you can see it is if you have that permission around seeing an unpublished event.

@2:24:52 - estevenson

Yes.

@2:24:52 - JD Leonard

And you could have an organizer kind of role where, yes, you want to be able to see unpublished events.

just stop All Correct. Even if they aren't your own. Yeah, and can view own event can be a little bit implied because it's not exactly usable if you can view own events.

Yeah, I mean, well, it wouldn't usually be implied.

@2:25:22 - estevenson

Usually we would make it explicit if we were providing that capability.

@2:25:37 - JD Leonard

But I'm going to remove it from potential future scope.

@2:25:42 - estevenson

Well, so if you can, it's conceivable that you could allow somebody to create an event, but then not view it.

@2:25:50 - JD Leonard

It's dumb, but you could do that, right? Yeah. So... So, okay, so let's... Yeah, let's... The can be seen if member status is X and can be seen if associated contact does or does not have tag X.

So I know exactly where you got those from.

@2:26:10 - estevenson

And let me think about that for a moment because I hadn't considered that in the context of just being able to see an event.

Yes, this is part of the point of the document. It feels very messy to me, but it just needs to be enough for people to think.

@2:26:26 - JD Leonard

No, that's exactly right. I also know we haven't established what member status is within the context of events. kind of like, but on the other hand, this is future scope.

@2:26:45 - estevenson

No, you're completely right.

@2:26:47 - JD Leonard

As it relates to event, we don't have a concept of a member. So that's not a thing here. That would be a member platform.

Okay, then I'm going to get rid of it.

@2:26:55 - estevenson

Hold on. Let me think about that for a second. That would be to be.

@2:27:00 - JD Leonard

More explicitly, that would be something relevant to CRM member, not exactly member platform. Okay, so I might add sort of relevant to CRM member integration bracket.

Right, so you could imagine, right, that one way to approach this would be to have a module, you know, CRM member event or CRM event member, right, that requires that you have both the CRM event module and the CRM member module, right?

@2:27:45 - estevenson

And if you have both those things, then this third module provides, you know, these options, right, this kind of option.

Yeah, no, and that is useful in terms of figuring out the starting thing because we might... Yeah, it's just sort of, we want to allow the ability to that to be expanded.

@2:28:04 - JD Leonard

The other approach would be to build that functionality in to either the CRM event module or the CRM member module.

And it just, it wouldn't be, they wouldn't have a hard dependency on one another. But if both are installed, the functionality lights up is kind of how it would work.

@2:28:28 - estevenson

So again, we don't have to get into the how.

@2:28:31 - JD Leonard

Yeah, this is not about the how. But yes, it is, in terms of the what, it is useful context.

Okay, so can be seen if associated contact does or does not have tag X that I don't think, yeah, beyond the fact that we're not going to do it at the start, I think that's just good on its own.

@2:28:54 - estevenson

And I can't think of other future scope in terms of viewability that... it. I This is where you have discussions and people sort of come up with scenarios.

Yes, they come up with their wacky use cases and they're like, well, actually. Yeah. So I think we're good for view.

So this says initial scope can't create events. But I think what you probably mean to write is can create event.

Okay, that works. That is better. Because you're trying to list like the options, right? But what we're actually, I think, want to list are the permissions that you may or may not have.

That sounds good. So can create event, we would say. Can create event available to any contact? Because I mean, part of me was thinking that, I mean, when it comes to member status, that I think am...

If of like a paying member or I'm an unpaid member and therefore I can only create public events, if I am paying, then, you know, kind of maybe I gain the ability that members who have been tagged with Y, you know, kind of like, and instead of kind of, you could have a scenario where instead of people paying to be paid members, you are like, I'm thinking of like role-playing games.

@2:30:30 - JD Leonard

Um, and, um, oh, like, I'm trying to remember the program, but anyways, what they have is they have the GM.

The GM can kind of create a tabletop session, um, and then they can kind of like specify people who are allowed to join, um, and the payment's happening on that end.

So it's happening on the create event end, but then gives them the ability to kind of specify who can join that.

I only want kind of like kind uh, uh, uh, I

@2:31:00 - estevenson

I am a volunteer coordinator. I am paying your organization so I can do this. And I only want volunteers who have been tagged with having kind of volunteered 10 times.

@2:31:14 - JD Leonard

So I don't know if that's, I mean, this is the point of the document. Do we support that at all or do we not worry?

It sounds like a lot of complexity. Yes. Whereas I think base level CRM event, can a user create the event?

Okay. Like, either they can or they can't. It's something that would typically be assigned like an organizer role, right?

I could see doing, I could see doing the tag thing, you know, can create event if they have a tag or something like that.

I like that.

@2:31:53 - estevenson

That's easier. Yeah, I feel like if we leverage the tag concept in a lot of places, then it becomes much more powerful.

That's... That's... That's... Yeah, then, yeah, no, and then you can kind of assign the complexity to how you assign the tag.

@2:32:05 - JD Leonard

If, and is it contact has tag or user has tag? Oh, no, no, good point. Oh, yeah, that's a very good question.

So the user is the thing that gets the permissions.

@2:32:27 - estevenson

Yes.

@2:32:27 - JD Leonard

A user's permissions could be influenced by things like relationships, you know, between other contacts and the contact that represents them.

So I'm just, I'm just sort of typing.

@2:32:46 - estevenson

Yeah, so, yeah, so can create, can create event if, if, if users, if users contact has tag. If users contact has.

so, so, so, so, so, yeah Tag. So I would remove the one above it about if a user has a tag.

We don't have a concept of a tag on a user. Okay, that makes it easy. Yeah, yeah, yeah. It's just if, like, the user's associated contact has a tag, and then I think it's very much a TBD around can create event if, you know, user's contact has a relationship of some sort, you know, like.

So, yes. For example. I'm going to add that here, so. Right, for example, if a user's contact has an employee relationship at an organization, maybe that allows them to create an event, right?

@2:33:43 - JD Leonard

But we're not going to. User's contact has relationship X.

@2:33:58 - estevenson

Is that a good way to put it? Is That's

@2:34:00 - JD Leonard

Actually, should we have can create event, if user has tag, that should probably go inside FutureScope, because we haven't introduced the concept of tags yet.

Well, that's true, the tags don't exist yet.

@2:34:15 - estevenson

So, yeah, so we're going to, I am just going to sort of leave this. And then there's also kind of like, do we want to separate that people can create events, but they can't update it?

And then you also have kind of, I can create event and update my own event. And then there's, I can create my event, any event, and I can update anyone else's event.

@2:34:38 - JD Leonard

Or theoretically, you could have kind of like... Yes, typically, you would have what we have here, plus you would have can edit any event, can delete any event.

Edit any event. Edit event. Participant event. Delete any event. And then I don't 100% love this, but we might want to reuse it the own event.

@2:35:09 - estevenson

Like maybe we do actually want the can edit own event and delete own event. Event can elite own event.

But yes, I mean, it's getting finicky, but we can always just hide these unless someone chooses to reveal the complexity.

Well, I mean, it would just be in Drupal's sort of giant permissions list, right? Yeah. Yeah, I just, I have this personal aversion to having the permissions be based on whether somebody, whether it's somebody's event, because, well, whether it's look at a different page of the name.

Thank It's weird. likelihood, other people should be able to edit it too, so who are those people? Yeah, yeah.

But yes, you could have someone where anyone can kind of submit me drafts, but then I only want to be able to edit it because I'm weird that way.

Sure. I would agree that I'm tempted to leave them out, but having the ability isn't bad. It's a pretty standard thing to have.

Yes. In Drupal. Okay. So kind of create event, can create own event, can edit any event, can delete any event.

Can create, edit, or delete event if user's contact has tag.

@2:36:59 - JD Leonard

Yeah. Just to sort of roll it up. Okay. Can create events available to contact with member status X.

@2:37:15 - estevenson

I'm happy to just delete that, but part of me was like... Yeah, how do... How...

@2:37:23 - JD Leonard

Pretty much do we want any user...

@2:37:27 - estevenson

You'd need to be able... I am trying to figure out how do you kind of like give permissions to interact with paid kind of contacts versus unpaid contacts?

And who does that belong to? Like, is it only on the RSVP?

@2:37:49 - JD Leonard

Or when it comes to creating events, is there anything that I want to be able to create an event that only paid members can go to?

Or is that the default? Or is Or Or Or

@2:38:01 - estevenson

Yeah, so you're saying for a given event that should be restricted, whose attendees should be restricted, should the creation of such an event be restricted?

Yes. Differently than the creation of any other event. Yeah. My gut reaction is it seems like a much more specific use case than like a general...

I'm happy to kick it out. Yes, and, you know, kind of tag X, I am also happy to kick that out.

@2:38:37 - JD Leonard

I would agree that if someone wants that, that maybe kind of you extend it, or we wait until we're actually eating dog food.

Yeah, I mean, I think having the ability for an event, for the possible set of events registrants to be...

@2:39:00 - estevenson

Restricted makes a lot of sense, but that also belongs in event registration. I am totally happy with that. Okay, so can create event if user's contact has relationship X.

And then, yeah, kind of another thing is that, yeah, you could have someone where you want them to be able to create an event, and you want them to be able to kind of RSVP kind of people on their own.

@2:39:29 - JD Leonard

That, you know, kind of, I want to create an event, and I'm RSVPing all my friends, you know, kind of like just automatically.

@2:39:37 - estevenson

Or maybe you don't want them to be able to RSVP, which again is... I think we can probably separate the concepts of creation of the event and the ability to RSVP other contacts.

I am happy to do that.

@2:39:50 - JD Leonard

But I think that's different than what you had there. What you had there was around allowing another contact to be an event owner.

You know, was thank reach Thank

@2:40:01 - estevenson

Oh, yeah, that's what that is what I was thinking, that you're kind of like, I own an event, but I want to share ownership of that event.

@2:40:13 - JD Leonard

That, you know, kind of, it's easy enough, I create an event, but, yeah, I want to be able to give someone else the same permissions as if they had created the event.

Yeah, it all comes down to, like, who gets to manage an event once it's created. Mm-hmm. So can add another event manager?

So manager is better than owner, because... Yeah, it's, um, it's kind of, it's tricky, because we're introducing this concept of, like, a role that's event-specific, right?

it's it's it's it's You Well, you know, at the same time, maybe I want to be able to create an event, and I'm the owner, and then I realize I can't do it, because that, and I actually do want to reassign ownership so the event can still happen.

@2:41:12 - estevenson

Right. We have this problem on Drupal.org, community events, where if I create an event, say, for the Austin Drupal users group, I am the only person who can edit that event.

Aside from, like, site admins, basically. And that is very limiting. What I'm trying to, like, think through is, like, is CRM event the right place to introduce a concept of an event manager?

Or is that more of a member platform-y kind of thing? It's not really specific to membership organizations. It's... It of more stems from, like, you know, the meetup.com feature set that we're targeting.

That, yeah, kind of being able to either reassign ownership because I've created this event. Oh, I can't do it.

@2:42:22 - JD Leonard

I want to be able to assign it to someone else. Or I want multiple people to be able to manage it.

Is a little, like, yeah, like that. That is a rabbit hole. But it is something that comes up.

@2:42:40 - estevenson

Let me think for a moment. I mean, as a default, that you could always just sort of...

@2:42:47 - JD Leonard

I mean, I definitely know for multiple, there's always the option that you just call up the administrator, and then the administrator does it, sort of as the initial workaround.

But this is actually inside potential... know if... I don't Future Scope, so. So. Can. Go ahead. Actually, so can add or remove another contact?

should probably do can replace. I actually think. Well, I think this comes down to do we have the concept of an event owner or just of event managers?

Well, event owner that insofar as I, when I create an event, I own it, but you're kind of that.

But that's a concept that we don't have to have, right? And I sort of realized that if we're going to have it, it should be a field on event.

I mean, yeah, I of, I mean, yes and no. There's whole bunch of data that's tracked on an entity that we might not list out here, like the created date and the updated date and stuff like that.

@2:44:11 - estevenson

So I would be very forgiving about those things not appearing here. But I think the decision about whether an event has an owner, which in Drupal is typically the author property on an entity, or not is a good one.

And my personal bias is that the concept of an owner of content is always problematic because it makes it hard.

@2:44:42 - JD Leonard

And that's where that, you know, edit own event comes from, right? But it makes it kind of hard to make that more flexible.

So we could be a little more opinionated and say, hey, we're not going to have a concept of an owner.

Okay, you created this event, fine. Maybe because you created the event, you become an event manager, right? And other people can be added as event managers.

Can add remove other user as, well, mean, it should just be can add remove user as event manager.

@2:45:33 - estevenson

And so should event manager exist as a defined field on kind of event? is this sort of? Yeah, so thinking this even more, you know, making this even more complicated, right?

You could imagine that you might want somebody to be able to manage an event, but not manage the managers of the event.

Yeah. But now we're talking about, you know, it's like an event admin versus an event manager or something.

@2:46:12 - JD Leonard

Now we've got these two levels of, you know, complexity. And maybe these concepts are not relevant to whoever's using the site, because they're basically going to just delegate that stuff based on relationships or, you know, based on some other logic.

Yeah, no, and there's also kind of, yes, and then imagining that, you know, kind of weird use case, I want to be able to display events, but I don't, and I want people to be able to create events and manage their own postings, you know, kind of which I would just sort of assign, I do think that this could be assigned to that manager, that my use case, I want to be able to create.

I want to have sub-users who can create events, and I want those people to be able to manage their own events, but I don't want any of your registration nonsense.

So, going in a different direction, so there's this ecosystem of modules called Group in Google. CRM provides integration with Group.

@2:47:25 - estevenson

I haven't used Group and CRM together yet. Okay. I haven't played around with that, but I could imagine that we use the Group module, which would probably be an optional thing, right, to provide some of this kind of capability.

So, each event would be its own group. Gotcha.

@2:47:51 - JD Leonard

group is of a certain group type, and the group type provides certain roles for that. Group type, which basically translates to roles for an event.

@2:48:05 - estevenson

And that's where you could have an event administrator, an event manager, you know, have those sort of things defined because the whole concept of group is to help abstract away, you know, those sorts of things so that.

Yeah, no, that makes sense that just as an integration for CRM and groups, we allow each event to create.

I mean, it sounds like two groups, event admins for this group, event admins for, sorry, event admins for this event, event admins for, sorry, event managers for this event.

So how do we kind of state that as a lot inside this? I think it's, I think it's, there probably would need to be.

@2:49:00 - JD Leonard

A CRM event group module where that sort of functionality would live. Okay.

@2:49:10 - estevenson

So CRM event group module expansion, or, yeah, I'm just going to say expansion, that allows each event to have an event admin and event manager group.

@2:49:50 - JD Leonard

I think that captures it. I mean, it's going a little bit outside of the scope, but it is something good.

It is a concept that's good to capture. It is a is that's that's a Yeah, and I think not an event admin, but right, allows each event to have event admins and event managers or something like that, right?

Have event admin and event manager group. Yeah, that's getting conceptually weird, but it is a good weird.

@2:50:27 - estevenson

But it is allowing us to push that out to the side, out of the core scope here, and not get distracted with things that we were about to be.

We have captured it. If someone asks about it, we can point at that.

@2:50:41 - JD Leonard

Right.

@2:50:43 - estevenson

Okay.

@2:50:45 - JD Leonard

And it won't get forgotten, so, or I mean, it will. And it could very well be, like, maybe that's too heavy-handed for some cases.

Like, I don't know, for example, whether member platform would necessarily. We rely on the CRM event group module to provide that capability.

We might, but for taking on group as a dependency is sort of a big step just because there's a lot there.

Yes. Now you're very highly tethered, right, to the intent of the of group. I would agree that having this as a potential future module that you add on to it and it has no dependencies is good.

And it's just relevant to this in case, yeah, like you have to imagine a permission like that. That's good enough.

And somebody could always, there are two easy approaches if somebody wanted to have an event.

@2:51:51 - estevenson

Well, maybe that's not easy. Well, yeah, sort of, if they wanted to add like event managers, right, they could add a field.

That is an entity reference to users. They could use ECA to say if the person viewing this event or the person editing this event is referenced by this field, then grant them access to edit the event.

@2:52:21 - JD Leonard

Okay. That's one thing you could do. another thing you could do is you could create a module like CRM event manager, right?

That just basically provides this stuff out of the box in a lightweight way, right?

@2:52:40 - estevenson

It's not like, whoop.

@2:52:43 - JD Leonard

So there are options, and I think that's what we want for the ecosystem is for there to be options to meet people's various needs.

@2:52:50 - estevenson

Okay. So I think we've done that, and I think that's it for, I'm just trying to think if there's other things for create event, because I've already managed to expand that.

@2:53:00 - JD Leonard

A lot more than I thought it would once I started thinking about it. Okay.

@2:53:07 - estevenson

I'm happy to move to CRM event registration.

@2:53:11 - JD Leonard

I think I unfortunately might need to break and put some food in my face. That sounds good. But I do look forward to continuing the discussion.

Okay. Let me just look briefly and make sure there's nothing in the mock-up notes that we glossed over as it relates to CRM event.

I mean, tips for a great event and publishing guidelines seems like a member platform-y kind of thing. Yeah. Where did we land on banner and icon stuff?

I think we just sort of, let's just put them in because there's no real reason not to have them.

@2:53:54 - estevenson

Let's put them in at least for discussion. other people want to kick them out, can have that discussion. Yeah.

How, whether the event is online, in-person, or hybrid?

@2:54:05 - JD Leonard

I know kind of like event location, so.

@2:54:10 - estevenson

But what I mean is, if I'm navigating to create an event, what do I do, right, to say that I want, like, I kind of feel like there should be a field that is.

Event location type? I think it could just be online, slash, in-person, slash, hybrid. Okay, that works for me.

@2:54:35 - JD Leonard

We also probably, we probably could get rid of the word event for all of these fields. It's true. Now that I'm thinking about it.

@2:54:45 - estevenson

I was just looking at it, I'm like, you know what? Every single one has a vent in it. I might, I might get rid of the, sort of, based on this, because, yeah, that was kind of like, being like, I don't know how to.

@2:54:59 - JD Leonard

I might kind kind Sort of prescribe what an event should be. Right.

@2:55:07 - estevenson

I will try to find some type of authority to back up what I said.

@2:55:14 - JD Leonard

Status. State. But yes, everything we already know is related to event.

@2:55:23 - estevenson

So location.

@2:55:28 - JD Leonard

So online. What was it?

@2:55:33 - estevenson

Online. In person and hybrid. In person. I struggle with how to, like, obviously those are the options, right? But I kind of struggle with how to label it.

I would agree. And to some extent, it's just, I can't think of another option.

@2:55:52 - JD Leonard

I guess it could be, like, delivery model.

@2:56:00 - estevenson

It's not quite right, but medium?

@2:56:07 - JD Leonard

Sure. I mean, location, type.

@2:56:15 - estevenson

It's not the type of location. Format. Format. That's a good one. Got one. Racking my brain on that one.

Yeah, no, no, the only thing I can think of is, like, proxy, where you have an event where you can't go, but only proxies can go, because, yeah.

That's me just trying to break things. Tell me about virtual location URL.

@2:57:00 - JD Leonard

So, um, there could be value in having that be separate from details to join, but I'm just trying to think, like, does a virtual location necessarily have a URL?

@2:57:13 - estevenson

Probably not. Yeah, I'm happy to get rid of it.

@2:57:17 - JD Leonard

That, like, so, yeah, like, I could think of that it could be a Zoom meeting. It could be kind of join this Discord chat.

But, like, I mean, kind of details to join. I mean, kind of gets us there, right? Well, I mean, sort of what might be nice is clickable link, um, that your kind of details to join could be kind of a series of instructions.

@2:57:44 - estevenson

But if kind of it is something where I can just click a thing without following instructions, um, that could be nice.

But no, no, no, I agree. What I'm, what I'm thinking through, though, is... It's like, details to join can be a WYSIWYG field, right?

@2:58:05 - JD Leonard

And if all you want to put there is just a link, you can do it, right? Yeah, no, I'm happy with it being a WYSIWYG field.

Part of me is just sort of, yeah. I think for, I don't know, I'm probably persuadable on this, but member platform might be more opinionated and say, hey, like, we're going to have this button that you can press if there's a URL or whatever, you know what I mean?

Yeah. But I don't, you know, maybe that does belong here. No, I mean, I'm not particularly opinionated myself. It just sort of, yeah, like I'm, you know, kind of part of me doesn't like details to join just because it's undefined, but it doesn't really need to be defined and it's...

you're going to... ...

@2:58:59 - estevenson

... ... Pretty variable.

@2:59:03 - JD Leonard

You know, going back to organizer notes, we removed it because we don't have this concept of an organizer, right?

But as we just talked through, you know, the CRUD permissions, it's really not about whether you're the organizer. It's about whether you can edit the event.

Yes. Right. So it's...

@2:59:24 - estevenson

Editor.

@2:59:25 - JD Leonard

Editor permissions.

@2:59:27 - estevenson

Yeah, it's like editor notes. But I mean, I don't really want to call it that. It's just kind of an awkward thing to call it.

Private notes implies it might be private to the person who is typing it, which is wrong. Or it could be wrong.

@2:59:52 - JD Leonard

Non-public notes. I'd be like, you know, you're thinking as part of...

@2:59:58 - estevenson

notes. Internal notes. notes. I think maybe we propose that as part of this.

@3:00:08 - JD Leonard

Like for both of them or just for virtual? Oh, sorry. For... As its own field? Yeah, both as its own field and as an odd location.

Okay. Physical location, probably. Internal...

@3:00:29 - estevenson

Internal... Notes. Internal... Notes. And I might just... AKA... Only viewable to edit tors. Oh, you have viable there.

@3:00:57 - JD Leonard

Oops. please. H

@3:01:05 - estevenson

I'm going to get rid of that, aka. Yeah, that's fine.

@3:01:44 - JD Leonard

I remember you said that you needed to go, so I am perfectly happy to kind of keep going, but I want to know that I'm procrastinating going.

@3:01:55 - estevenson

I was just reviewing anything else in the mock-up notes that might have been relevant. I don't know. I think we've got it at all.

Yeah, no, I think conceptually it's better defined and then, yeah, we need to sit down with event registration and do that and then have other people go through it and, yeah.

@3:02:16 - JD Leonard

Another thought here, okay, this is the representation of an event. What does this look like when it gets output on a page, right?

Like what is, what happens if I navigate to an event to view it? What does it look like?

@3:02:39 - estevenson

And do, you know, do we provide any way to view a list of events or a calendar of events?

Yeah, like I think I, just a sec, provide a listing and calendar views for events. So I've at least captured that inside the summary, even if I haven't.

@3:02:59 - JD Leonard

list I've

@3:03:02 - estevenson

I mean, I definitely could just go on MS Paint and, well, not MS Paint, but yeah, I definitely could try to do sort of a mock-up.

It would be very generic.

@3:03:15 - JD Leonard

I don't think, I don't think there's much need for that. think people have a general sense for what that looks like.

@3:03:19 - estevenson

We'll need to get more specific, obviously, about exactly what goes on, you know, exposed there. But we, we already have some of that on the mock-up notes, right, that we can kind of adapt.

Yeah, that, so I could add just sort of, in addition to that, yes, so kind of views of event, if we wanted to.

So I've got event management, so event views. We could sort of detail that out. Do we want to do that?

I can sort of. you could just copy, you can copy a lot of the stuff from the list of events page.

List of events. Let's see. Event detail page, list of events page. So I'm just going to do... And there's a calendar of events page there, too.

Okay. I'm going to do... What'd you do? Okay. Event views.

@3:04:32 - JD Leonard

And then I am going to add header 3. Listing. Okay.

@3:04:44 - estevenson

And then underneath that, I am going to... Well, first I'm just going to copy it wholesale. Sure. And then I'm going to get rid of anything that...

That is related to RSVP status.

@3:05:05 - JD Leonard

I'm just going to go like this, because we're going to find that elsewhere. Status, clicking on event, will take user to event.

I'm just going to do list of events page. I can copy the JPEG, too, if you want. I don't know hard.

Yeah. And again, all that stuff is so out of date and not with what we're talking about now.

@3:05:34 - estevenson

But I was just having a thought about big picture thought here. The event state. Because status is being saved for published, unpublished.

So. So. So. Thank So all the stuff that we just detailed for CRM event, can you point to anything in the initial scope that has to do with CRM?

No.

@3:06:33 - JD Leonard

Pretty much sort of like, I mean, I wouldn't be surprised if we just sort of like look at this list of requirements.

We look at that event sort of module, and then we're like, we can just use that event module. I think the event module has some issues, but it could very well be that maybe this should be the event module.

Pretty much, yeah, kind of that part of me.

@3:07:00 - estevenson

Just because you pointed out registration, you know, kind of like where you're attaching that to an entity, that, yeah, like, it is confusing because it's just sort of like, if we're not using some other module for event, we're creating our own event, you know, just sort of like that simple and basically just a thing that we can attach CR event registration to.

@3:07:26 - JD Leonard

Right. And yeah, like we're in said real danger of reinventing the wheel. But what I, yes, yes, 100%. That's kind of why I'm bringing it up.

And also, like, it may be that the existing wheel is not very good. That is valid. That, you know, kind of, and plus.

So we should, you know, we should strive to ensure that whatever wheel, whatever the best wheel is, is the wheel that we are using and possibly creating.

Yeah. And, you know. Kind of a fairly lightweight module that just provides the, yes, I mean, what a lot of other event modules are doing is that they're trying to do more stuff than this is doing, where for this module, all we're really doing, like, I would agree that CRM event is a bit of a weird name for it.

It's hence why it's just sort of like, I'm not even referring to a module.

@3:08:24 - estevenson

This is bundle of functionality. Right, right, right, right. In the document, I think you had, where do go? You had referenced the events project.

Yes. And

@3:09:00 - JD Leonard

This is where I struggle because Martin has done all of this work in the recipes sort of silo for events.

But because we're not actually building recipes, we can't have a module depend on the recipe. Mm-hmm. So this is like simple event where kind of, yes, sort of what he's doing involves so much fancy functionality that kind of is very nice to sort of use.

@3:09:36 - estevenson

But to some extent, we just want a thing that we can attach event registration to. And I mean, one advantage of doing that is that, you know, kind of we're also effectively creating an interface where if your module provides all the things, then you can do your own hook.

@3:09:56 - JD Leonard

I don't know. Yeah. Kind of what you're getting at is like, hey, we need a way to point to an event entity that's an event entity type, right?

That is what we're going to use for event stuff.

@3:10:13 - estevenson

And it has to support certain things, right? Yeah.

@3:10:18 - JD Leonard

And you're kind of... Yeah, I don't know that we're going to get to the level of complexity of having a pluggable event entity system.

But yeah, kind of that pretty much event registrations is where it's going to get opinionated and actually involve sort of CRM stuff.

And this is more creating a puzzle piece and kind of that our thing is going to fit. Yeah. I'm just re-describing an interface.

@3:10:53 - estevenson

So in addition to the... Events recipes project that you linked to.

@3:11:03 - JD Leonard

I'm putting in Slack a link to the event project. That sounds amazing. We should put any important references that make sense.

Which is doing some of the stuff that we're doing. I don't know that they're doing it as well. you adding it or are you texting me to add it?

I just put it in the Slack to you. Okay. I'm going to do that. Investigate that further maybe. Because...

Eh, just become a link. Why are you making this difficult? Cert link. Here we go. go. But I think that this is basically used by the Conference Organizing Distribution, or COD, and I don't know that it's used by anything else.

But let's see. No, it is used by something else because this event module is installed more times than COD is.

@3:12:45 - estevenson

I do, yeah, I mean, it deserves more, a more detailed deep dive, but it, oh, I know.

@3:12:53 - JD Leonard

I think I had installed this, and I was like, it makes some assumptions. Like, what was it here? Well, in any event, it is an implementation detail, and perhaps some of what we are talking about will be something we end up contributing to that and then leveraging that.

You know, instead of building our own CRM event entity, which is, think we just discussed, like, we haven't actually defined anything specific to CRM.

No, I would agree that there's nothing prescriptive about the event bundle of functionality. Because, yeah, it's not really a proper module.

It is a list of requirements that we should investigate slash sort of modify into something else.

@3:13:57 - estevenson

And now I'm remembering that I had messaged them. Amen. Thank Container of that about a week ago, and he didn't get back to me.

Well, I'm going to make a note for myself to follow up with him about that. Yeah. Because I was just going to be like, hey, what are you doing?

Let's find out and see how compatible this would be with our needs. So kind of on the plus side, we've got a list of needs.

Yes, yes, 100%. That's very helpful because it makes the evaluation of it a lot easier.

@3:14:33 - JD Leonard

Like, hey, what are the gaps?

@3:14:35 - estevenson

Yeah, yeah. So, yeah, one thing that could be helpful if you have the time would be to see what the gaps are between our list of needs and what event provides.

Okay, so we should, could we, I'm going to come up with a to-do comment at the start. good. For myself, if that is okay.

Oh yeah. Just because otherwise I will forget everything that you say. I know the feeling. Okay, so...

ACTION ITEM: Investigate Event module + Event Group/Group Events; document gaps; follow up w/ maintainer - WATCH

@3:15:13 - JD Leonard

Okay, come on, just get on the thing.

@3:15:16 - estevenson

Okay, so two do's. Okay, so one was investigate event module. Was it events or event? Event. Okay, module. Event module to determine gaps.

@3:15:38 - JD Leonard

To determine gaps for our documented needs.

@3:15:51 - estevenson

Okay, and then the other one was... And yeah, no guarantee I'll get to them, but I'll at least have them recorded.

it um Install event registration, entity registration, entity registration, entity registration, and was like something like include document what it does inside our event registration, CRM event registration bundle of functionality.

Yeah, just to understand, right, what is the out-of-the-box functionality that that provides that we could leverage, and what are we proposing beyond that?

Document out-of-the-box functionality that That is relevant to what we're trying to do. I am going to get that, sorry.

@3:17:16 - JD Leonard

Yeah, don't worry. Hello. Speaking. I am good. So I think those are the to-dos. I am just going to sort of comment and then go to editing it, just so that it's, don't forget.

With the event module, you might also look at, on their event page, on the project page, it links to some modules that extend it, event group and group events.

Investigate modules that extend event module. Yeah, I think there are just two there, and I think you're going to want to probably install those as well, at the same time, to understand like what, I mean, maybe you want to do just event first, and then, you know, see what each one adds.

@3:18:55 - estevenson

But I think that's going to help. going do, bye. Thank you. Identify the full set of functionality. Yeah.

@3:19:03 - JD Leonard

Now, one thing you should know. Okay. That is all related to the group module.

@3:19:10 - estevenson

The group module takes some time to grasp. Okay.

@3:19:19 - JD Leonard

But I think that it is a very powerful suite of modules that is worth taking the time to understand.

@3:19:29 - estevenson

Particularly in the context of CRM already integrates with the group module.

@3:19:36 - JD Leonard

So to have a full understanding of CRM and what it can do, it's necessary to understand group and what it can do and how the two work together.

Yeah. So, yeah, I mean, if I can find time, that sounds like it's a good way for me to take a stab at it and, you know, possibly sort of gradually wrap my head more around Drupal.

Yeah. Identify the full set of functionality. Yeah. Now, one thing you should know. Okay. That is all related to the group module.

The group module takes some time to grasp. Okay. But I think that it is a very powerful suite of modules that is worth taking the time to understand.

Particularly in the context of CRM already integrates with the group module. So to have a full understanding of CRM and what it can do, it's necessary to understand group and what it can do and how the two work together.

Yeah. So, yeah, I mean, if I can find time, that sounds like it's a good way for me to take a stab at it and, you know, possibly sort of gradually wrap my head more around Drupal.

Yeah. Yes, yes, that's what I'm getting at. And group is the kind of thing that you should seek out a tutorial video on it, not try to figure it out yourself by installing it.

Sounds good. No, part of me has been thinking of just spending money on Drupalize.me and just spending time just learning.

Sure, sure, sure, sure. Yeah, no, that's a good plan, probably. Yes, this is still a spare time thing, but it's good spare time thing.

Yeah, yeah, yeah. Okay, well, Erica, thank you so much. Much too. to seeing, you know, how you get on and look forward to hopping on another call to work through more stuff here.

Okay, amazing. Take care, have a good day. Bye-bye.