>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3557286. --> Reported by: [jdleonard](https://www.drupal.org/user/80902) >>> <h2>0&#65039;&#8419; Who is here today? Please post your <a href="http://Drupal.org">Drupal.org</a> username if you have one. We provide issue credit for those contributing to the meeting beyond this thread. Especially if this is your first meeting, please mention a club, association, meetup group, non-profit or other membership organization (MO) you think could benefit from this initiative and/or tell us why you&rsquo;re joining us.</h2> <table> <tr> <td>beautifulmind</td> <td>Beautifulmind</td> </tr> <tr> <td>Scott Wolpow</td> <td>scottwolpow</td> </tr> <tr> <td>jdleonard</td> <td>JD Leonard (jdleonard). Zilker Neighborhood Association</td> </tr> <tr> <td>Lee Walker (mr_scumbag)</td> <td>Lee Walker (mr_scumbag)</td> </tr> <tr> <td>James Shields</td> <td>James (lostcarpark).</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Bob Snodgrass (bsnodgrass) St Charles IL (Chicago Area) Fox Valley Drupal</td> </tr> <tr> <td>paulmckibben</td> <td>paulmckibben - Atlanta Drupal Users Group</td> </tr> <tr> <td>richgerdes</td> <td>Rich Geedes (Richgerdes)</td> </tr> <tr> <td>svendecabooter</td> <td>svendecabooter - local Drupal User Group Belgium &amp; some potential clients</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Open your own thread in the next numeric order or reply to this thread and I'll do it.</h2> <table> <tr> <td>Scott Wolpow</td> <td>Yes, can we determine our target market. Are we going after the Drupal experts or the person who is just starting out?</td> </tr> <tr> <td>jdleonard</td> <td>Created thread 8&#65039;&#8419;</td> </tr> </table> <h2>2&#65039;&#8419; Install CRM and get support. Reply to this thread for help getting CRM installed or for other support requests about CRM during this meeting.</h2> <table> </table> <h2>3&#65039;&#8419; Tell us that you have CRM installed locally! What version? This is to encourage folks to get it installed so they can test and file bugs and feature requests.&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>Scott Wolpow</td> <td>I have beta 5 and will update this weekend</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I have it installed on a test site, I need to upgrade it. Not today or tomorrow however, maybe get back to it over the weekend or early next week.</td> </tr> <tr> <td>James Shields</td> <td>I have been working with the Dev version, so have had a few reinstalls when things have broken!</td> </tr> <tr> <td>jdleonard</td> <td>I'm working off of HEAD.Not related to that choice, everyone who followed the instructions on the project page should run ddev add-on get ddev/ddev-drupal-contrib&nbsp; again due to an upstream bug related to symlinking. Explanation <a href="https://github.com/ddev/ddev-drupal-contrib/releases/tag/1.1.5">here</a>.</td> </tr> </table> <h2>4&#65039;&#8419; What fields should CRM provide for Contacts (not necessarily attached to Person/Household/Organization by default) that it doesn't already?</h2> <table> <tr> <td>Scott Wolpow</td> <td>I am a minimalist. I think citation, First Name, Last Name , Phone and email with a radio for preferred communication</td> </tr> <tr> <td>James Shields</td> <td>I would argue for keeping the default list fairly minimal. It's fieldable, so sites can add whatever fields they needs. If we want to provide expanded "quickstart" configurations that are closer to what organisations will actually need, recipes would seem a good way to do this without impacting people who want to start with a minimal configuration and add their own preferences.</td> </tr> <tr> <td>jdleonard</td> <td>What do y'all think about shipping some (less commonly used than Name, Email, etc.) fields unattached (they'd still need to be added to one or more Contact Types by a site builder via Field UI's "add existing field" flow) so that they are well-known to other modules in the ecosystem?</td> </tr> <tr> <td>Scott Wolpow</td> <td>I like the idea of premixed recipes</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>We could certainly add some recipes in the future for any special use cases, but I agree we should plan minimal since we can add fields, as needed&nbsp;(edited)</td> </tr> <tr> <td>James Shields</td> <td>@jdleonard Do you mean fields provided by the CRM module, or by other modules? Are you thinking Composer dependencies, so something closely bound to CRM?</td> </tr> <tr> <td>James Shields</td> <td>If there's benefit in having a tightly coupled field, then I have no objection. If it's just something that's useful for a contact, then it seems likely it would also be useful to unrelated entities, so it probably makes sense to be in its own project so any site and avail of it and it's not tied up in CRM.</td> </tr> <tr> <td></td> <td>And again, recipes are a good way of including CRM and any needed field modules without creating hard dependencies in the core CRM module.</td> </tr> <tr> <td>Scott Wolpow</td> <td>@James Shields Is there a way we can provide these without composer?</td> </tr> <tr> <td>jdleonard</td> <td>I'm on the fence about adding a bunch of fields to the CRM project itself.</td> </tr> <tr> <td>jdleonard</td> <td>It wouldn't necessarily add hard dependencies (@Steve Ayers has proposed that additional dependencies e.g. <a href="https://www.drupal.org/project/social_link_field">Social Link Field</a> could be dev dependencies that "light up" when the dependencies are enabled).</td> </tr> <tr> <td>jdleonard</td> <td>An argument for adding more fields is to have a larger set of well-known fields that folks can standardize on using, rather than everyone creating their own fields for the same purpose.</td> </tr> <tr> <td>jdleonard</td> <td>That facilitates folks contributing enhancements to the ecosystem without unnecessary duplication.</td> </tr> <tr> <td>James Shields</td> <td>Dev dependencies are a good idea, as it means they can be included in test cases without requiring them on production sites that don't need them.</td> </tr> <tr> <td>jdleonard</td> <td>Agreed. In my mind the question is more about what fields should/shouldn't be part of the CRM project itself. We could use a written policy.</td> </tr> <tr> <td>James Shields</td> <td>A standard list of fields is a good idea, but I'm not sure it should be included by default. For the initial release it could be just a documentation page linking to recommended modules. As we move forward, we could move these into recipes that install CRM and any required fields, and configure contact entities appropriately.</td> </tr> <tr> <td>richgerdes</td> <td>Are contacts a bundled entity type?</td> </tr> <tr> <td>jdleonard</td> <td>Yes, Contacts have bundles (Contact Types)</td> </tr> <tr> <td>richgerdes</td> <td>Makes sense. Can we leverage <a href="http://schema.org">schema.org</a> in some way to create our default fields or generate new bundles?</td> </tr> <tr> <td>Scott Wolpow</td> <td>@richgerdes Great idea</td> </tr> <tr> <td>James Shields</td> <td>That is an excellent idea!</td> </tr> <tr> <td>richgerdes</td> <td><a href="http://Schema.org">Schema.org</a> has the concept of a "Thing" which is the most basic object and the bridge between people and orgs</td> </tr> <tr> <td>jdleonard</td> <td>I'm somewhat in favor of this, but wary of the sheer volume of fields and relationships it would require to fully adopt the standard, knowing that some fields would see very little adoption. E.g. "duns", "callSign", and "dissolutionDate" are probably pretty obscure for likely uses of Drupal CRM.</td> </tr> <tr> <td>jdleonard</td> <td>I'm definitely in favor of providing the relevant microdata for whatever we do implement.</td> </tr> <tr> <td>richgerdes</td> <td>Oh yeah, i think the path would be to only create the minimal fields we want by default. The user should be able to add more having too many is overwhelming and silly given the way drupal works</td> </tr> <tr> <td>Scott Wolpow</td> <td>A duns number, It's been a while since I have seen that used</td> </tr> <tr> <td>richgerdes</td> <td>Helps a void us needing to nane things. We could provide a default "person" and "org" bundle if we want</td> </tr> <tr> <td>jdleonard</td> <td>Drupal CRM provides Person, Organization, and Household out of the box</td> </tr> <tr> <td>jdleonard</td> <td>Back to the original question &#128578; "What fields should CRM provide for Contacts?"</td> </tr> <tr> <td>richgerdes</td> <td>I would think since "contacts" should be contactable, providing a default field for name, address, email, and phone seems logical. They may be bundle specific though. I've also always thought drupal should have a "location" module of some sort for managing places (offices, stores, homes, etc). So it may make sense to break some of those off of the contact themselves (think our reusable meetup locations)</td> </tr> <tr> <td>James Shields</td> <td>Is there a way we could tie in with the <a href="https://www.drupal.org/project/schemadotorg">Schema.org Blueprints</a> module?</td> </tr> <tr> <td>Steve Ayers</td> <td>@richgerdes The contact detail entities (Address, Email, Telephone) are fieldable have a field for the kind: office, main, home.&nbsp;(edited)</td> </tr> <tr> <td>richgerdes</td> <td>Seems like an interesting way to handle it. Would have to play around with it more</td> </tr> <tr> <td>jdleonard</td> <td>As an example, the Contact entity type has an "emails" field that uses <a href="https://www.drupal.org/project/primary_entity_reference">Primary Entity Reference</a> to reference Contact Detail entities of type Email. That could be used to map to <a href="http://Schema.org">Schema.org</a>'s definition of a Contact having one email address.</td> </tr> </table> <h2>5&#65039;&#8419; What Relationship Types (e.g. employee, head of household) should CRM provide out of the box?</h2> <table> <tr> <td>James Shields</td> <td>I must confess I haven't looked at relationships in detail, but I'm assuming we have a bundleable entity type for relationships, and sites can create the relationship types they need?</td> </tr> <tr> <td>jdleonard</td> <td>Correct. There are fieldable Relationship Types&nbsp;(edited)</td> </tr> <tr> <td>James Shields</td> <td>If that's the case, I would argue for the default CRM installation to have none preconfigured, as any relationship types make assumptions about what the site is using contacts for.</td> </tr> <tr> <td>James Shields</td> <td>It would probably also make the case for having at least one recipe available as early as possible (preferably in time for DrupalCon Chicago) so there is a demonstration of a fully kitted out CRM install ready to go.</td> </tr> <tr> <td>Scott Wolpow</td> <td>I agree default should not assume anything</td> </tr> <tr> <td>jdleonard</td> <td>I think there's value in there being well-known Relationship Types that the ecosystem can leverage intelligently.However, I see the point of not introducing a bunch of likely irrelevant Relationship Types, which a site builder might need to delete.Thoughts @Steve Ayers?</td> </tr> <tr> <td>Steve Ayers</td> <td>I want to making migrating from CiviCRM as easy as possible. We currently have the same or similar relationship types as CivCRM.</td> </tr> <tr> <td>jdleonard</td> <td>@Steve Ayers couldn't the relevant migration module provide any needed Relationship Types (including and custom ones that might have been created in Civi)?</td> </tr> <tr> <td>jdleonard</td> <td>Drupal Commerce Core goes out of its way to provide a blank slate. Commerce Kickstart provides a demo of possible configuration. The difference compared to CRM is that we're building the base for an ecosystem to leverage. I think that includes Relationship Types, but I'm not sure where they should live.</td> </tr> <tr> <td>svendecabooter</td> <td>We could probably leverage recipes to create a setup that resembles civicrm config, and then migrate to that... Indeed like the commerce example, where I think Kickstarter is also a recipe now</td> </tr> <tr> <td>jdleonard</td> <td>One challenge with recipes is that modules can't depend on them.For example, if a recipe provided some Relationship Types for familial relationships, a "CRM Family Tree" module that would visualize those wouldn't be able to depend on those Relationship Types.However, if the Relationship Types are defined in a module, the CRM Family Tree module could depend on that module. And a competing "CRM Better Family Tree" could leverage the same well-known Relationship Types.</td> </tr> <tr> <td>jdleonard</td> <td>For CRM, thus far I think the best use cases for recipes are:DemosConfiguring CRM ecosystem modules for specific niche use cases (e.g. neighborhood association websites or meetup groups) + some default content specific to those use casesI'm wary of using recipes to provide entities that we want to be used by the broader ecosystem, which may include modules that can't depend on them.</td> </tr> <tr> <td>svendecabooter</td> <td>That makes sense... Perhaps another approach would then be to have multiple modules depending on each other?Core CRM moduleCRM Family (depends on core CRM - comes with default config / content, eg relationship types)CRM Family Tree (depends on CRM Family)</td> </tr> <tr> <td>svendecabooter</td> <td>The CRM Family module could even bundle a recipe, although that is not applied by default when the module is installed, so probably not the best workflow</td> </tr> <tr> <td>jdleonard</td> <td>I favor the multiple module approach. If we assume that approach, the next logical question is: which Relationship Types ship in which modules (inc. CRM)?</td> </tr> <tr> <td>Scott Wolpow</td> <td>Here is what I need to build, its multi-tiered:Think of a large company.The home office can control all the data at every level and branch. A person at each location may be assigned to CRUD contacts at that location, and each person can RU their own.A&nbsp; branch can only edit contacts within their own branch. Each branch has departments where some people can CRUD within that department.Now I don't think this should be out of the box with CRM, how would it get applied?Would it be interfere with how CRM is built?What I am looking at is using groups and entity relationships. That's hard to implement into an easy to use dash . So not really what I need.</td> </tr> </table> <h2>6&#65039;&#8419; As someone evaluating <a href="https://www.drupal.org/project/crm">Drupal CRM</a> (and based on what you know about CRM), what would you expect to see on the CRM project page that isn't already there?</h2> <table> <tr> <td>jdleonard</td> <td>I think it would be helpful to explicitly state that customization via site building is generally necessary to meet the needs of any given site using CRM</td> </tr> <tr> <td>Scott Wolpow</td> <td>My first needs for a CRM are:Company NameBrand Name (DBA)Parent company (with possible relationship)Address 1Address 2CityStateZipClaimed -Which will allow adding more informationigHoursType etc</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I will look later</td> </tr> </table> <h2>7&#65039;&#8419; Mockups for Member Platform. Who volunteers to create some updates mockups?</h2> <table> <tr> <td>Scott Wolpow</td> <td>What exactly is needed?</td> </tr> <tr> <td>jdleonard</td> <td>@Bee Low did some mockups, but we haven't heard from him in a while and they never made it past his first draft. <a href="https://docs.google.com/document/d/1c9GRue54-H1N4FRck1n5LWWAdFF0kJWv79bMtOSiEU0/edit?tab=t.0">This doc</a> (which links to Bee's mockups) has some notes to inspire what should be illustrated. The goal of the mockups is to facilitate alignment among contributors for what Member Platform (inc. its dependencies) will offer for 1.0.</td> </tr> <tr> <td>Scott Wolpow</td> <td>I can try to see waht I can do, I am really bad at graphics, but I can use gen AI LOL</td> </tr> <tr> <td>jdleonard</td> <td>Yeah, please don't do that. We need something multiple people can contribute to / iterate over time.</td> </tr> <tr> <td>Scott Wolpow</td> <td>Ok, will try in graphics</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Thanks for adding the link to the thread J.D. I will look later</td> </tr> <tr> <td>James Shields</td> <td>I think Bee was using Illustrator, which can create great looking graphics, but is kinda tied to him for updates. Would something like Figma be a better tool for producing something that multiple people can contribute to?</td> </tr> <tr> <td>jdleonard</td> <td>@James Shields For sure!</td> </tr> <tr> <td>James Shields</td> <td>I can tinker with converting Bee's mockups to Figma basic (free) plan, and see where we go from there.</td> </tr> <tr> <td>jdleonard</td> <td>I've used and liked Balsamiq before. Looks like we could apply for free use of their cloud offering: <a href="https://balsamiq.com/nonprofits/">https://balsamiq.com/nonprofits/</a></td> </tr> <tr> <td>James Shields</td> <td>I have no strong preference for any specific platform.</td> </tr> <tr> <td>jdleonard</td> <td>I'll submit Balsamiq's form and see if they bite</td> </tr> <tr> <td>Scott Wolpow</td> <td>@jdleonard Thanks</td> </tr> </table> <h2>8&#65039;&#8419; Member Platform target market</h2> <table> <tr> <td>jdleonard</td> <td>Thread proposed by @Scott Wolpow</td> </tr> <tr> <td>jdleonard</td> <td>From the <a href="https://www.drupal.org/project/member">project page</a>:MissionTo leverage Drupal to increase the efficiency and effectiveness of membership organizations globally, especially those with low technical or financial resources, so that they can positively impact their communities; andTo build an open and welcoming community of individuals united in their passion for serving membership organizations through Drupal.VisionTo provide a Drupal-native ecosystem of secure, privacy-enhancing, integrated, beautiful, and user-friendly tools that initially can meet many of the operational needs of at least 80% of membership organizations globally that have zero to five staff members (including all-volunteer organizations); andTo facilitate the existence of (but not implement) affordable turnkey software-as-a-service solutions to empower membership organizations to more immediately and sustainably benefit the communities they serve.Note: while the focus of Member Platform is on the needs of smaller less well resourced organizations, the feature set will be attractive to larger or more well resourced organizations too!&nbsp;(edited)</td> </tr> <tr> <td>jdleonard</td> <td>@Scott Wolpow Is there additional definition you're seeking?</td> </tr> <tr> <td>Scott Wolpow</td> <td>Nope</td> </tr> </table> <h2>9&#65039;&#8419; Migration from CiviCRM to Drupal CRM</h2> <table> <tr> <td>jdleonard</td> <td>Does anyone with experience in migrations want to try their hand at <a href="https://www.drupal.org/project/crm/issues/3537020">this</a>?</td> </tr> <tr> <td>jdleonard</td> <td>This will also help identify any gaps in Drupal CRM's data model relative to CiviCRM.</td> </tr> <tr> <td>Scott Wolpow</td> <td>I am dealing with Civi and would love to look into this as I do a D7 to D11 Migration with an upgrade on Civi</td> </tr> <tr> <td>jdleonard</td> <td>@Scott Wolpow Great! Let us know how it goes.</td> </tr> <tr> <td>Scott Wolpow</td> <td>@jdleonard I will</td> </tr> </table> <h2>1&#65039;&#8419;0&#65039;&#8419; Seeking suggestions for what to rename CRM's "Detail Type" to</h2> <table> <tr> <td>jdleonard</td> <td>Not to be confused with "Contact Detail Type", which is different.</td> </tr> <tr> <td>richgerdes</td> <td>I question why the above list isn't 1 or more taxonomies. I guess the main value is the machine name, but are these config? Do they need their own entity type? Do we intend to have logic proceeded based on these?</td> </tr> <tr> <td>jdleonard</td> <td>Yes, Contact Detail Type is a config entity type.Personally I'm not a fan of Vocabularies (there's a bunch of legacy baggage there), but I do find the current setup a bit odd.I think @Steve Ayers was keen to not have multiple vocabularies because it would result in one "Home" for address and another for "Telephone" and another for "Email". And, by allowing the different ContactDetailTypes to share DetailTypes (we gotta rename this), it would be straightforward to list/group a Contact's "Home" ContactDetails.</td> </tr> <tr> <td>Steve Ayers</td> <td>Rename to 'Detail Kind'</td> </tr> <tr> <td>jdleonard</td> <td>Look, I even managed to confuse it in my last reply here...+1 to renaming Detail Type to Detail Kind</td> </tr> <tr> <td>Steve Ayers</td> <td>Actually, what about Detail Location, or just Location?</td> </tr> <tr> <td>Steve Ayers</td> <td>CrmContactDetailLocation?</td> </tr> <tr> <td>jdleonard</td> <td>It's not strictly a location. Of the defaults we provide. "Main", "Billing", and "Fax" are not really locations. Presumably site builders might add more that aren't.</td> </tr> </table> <h2>1&#65039;&#8419;1&#65039;&#8419; status of CRM membership</h2> <table> <tr> <td>svendecabooter</td> <td>I assume the main focus is currently on the CRM project itself, but I wonder what the status of membership is</td> </tr> <tr> <td>svendecabooter</td> <td>I saw <a href="https://www.drupal.org/project/crm_membership">https://www.drupal.org/project/crm_membership</a> but not a lot of activity there</td> </tr> <tr> <td>svendecabooter</td> <td>I'm evaluating CRM for a member organisation (with yearly membership) but I'm wondering if it's still too early stages...</td> </tr> <tr> <td>jdleonard</td> <td>crm_membership will probably be a while, but CRM ships with a basic "Member" Relationship Type that could be used and extended as needed&nbsp;(edited)</td> </tr> <tr> <td>jdleonard</td> <td>I plan to track annual memberships in CRM for my local neighborhood association once it enters Beta</td> </tr> <tr> <td>svendecabooter</td> <td>Thanks for the feedback - will investigate some more.There might be 2 levels of membership though, not sure if the Relationship Type can account for both...e.g.Contact X is member of Company AContact Y is member of Company Bvs.Contact X / Company A has an annual membership with [my organisation whose website they are on]</td> </tr> <tr> <td>Steve Ayers</td> <td>"[my organisation whose website they are on]" -- This is contact 1I expect the member relationship type with the crm_membership module will be able to handle those two, and several more membership types.</td> </tr> </table>