>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3590134. --> Reported by: [jdleonard](https://www.drupal.org/user/80902) >>> <h2>0&#65039;&#8419; Who is here today? Please post your Drupal.org username if you have one. We provide issue credit for those contributing to the meeting beyond this thread. Especially if this is your first meeting, please mention a club, association, meetup group, non-profit or other membership organization (MO) you think could benefit from this initiative and/or tell us why you&rsquo;re joining us.</h2> <table> <tr> <td>Scott Wolpow</td> <td>Scott Wolpow (scottwolpow)</td> </tr> <tr> <td>mradamjohn</td> <td>MrAdamJohn</td> </tr> <tr> <td>jdleonard</td> <td>JD Leonard (jdleonard)</td> </tr> <tr> <td>miwayha</td> <td>Michael Harris (miwayha) -- first time at this slack meeting, but enjoyed learning about member platform at drupalcon</td> </tr> <tr> <td>James Shields</td> <td>James (lostcarpark)</td> </tr> <tr> <td>mortona2k</td> <td>Andrew Morton - mortona2k - Freelock/MindSing</td> </tr> <tr> <td>bdanin</td> <td>Brian Danin - bdanin - MindSing</td> </tr> <tr> <td>Steve Ayers</td> <td>BlueGeek9</td> </tr> <tr> <td>freelock</td> <td>John Locke (freelock)</td> </tr> </table> <h2>1&#65039;&#8419; Please open your own thread in the next numeric order (after thread 10) to start a threaded discussion on a topic. Or, reply to this thread and I'll do it.</h2> <table> </table> <h2>2&#65039;&#8419; Member profile and directory</h2> <table> <tr> <td>mradamjohn</td> <td>:grin:</td> </tr> <tr> <td>mradamjohn</td> <td>TL;DR I believe there are presently 5 open questions in this area:1.0 simplification profile-level privacy only, defer field-level to 1.1? <a href="https://www.drupal.org/project/member/issues/3515737">d.o #3515737</a>Organizer module bundled in Member Platform, or separate contrib carve-out? arch map &sect;3Profiles vs. Relationships &mdash; directory renders Contact directly, or via Profile wrapper? &mdash; <a href="https://www.drupal.org/project/member/issues/3515737">d.o #3515737</a>URL pattern &mdash; /members/{username} vs /members/{contact-id}? &mdash; arch map &sect;5Profile photo fallback &mdash; Gravatar / initials / placeholder? &mdash; arch map &sect;5</td> </tr> <tr> <td>mradamjohn</td> <td>jdleonard in #member-platform was a useful previous discussion</td> </tr> <tr> <td>jdleonard</td> <td>Thanks for taking the lead here Adam!I'd say:Simplify for 1.0Organizer role bundled in MPNot sure I understand the questionIMO we should avoid using username. Not all contacts/members have a mapped user. Username may be email addressed based and contain PII we shouldn't force to be more public than expected. Contact ID seems best for now. I think Drupal's pattern would be the (singular) /member/{contact-id}Feels like a nice thing to make configurable, but for 1.0 just use initials?</td> </tr> <tr> <td>mradamjohn</td> <td>3. is probably the most in need of further discussion.</td> </tr> <tr> <td>mradamjohn</td> <td>Agreed on all, and actually what I've done in my little tests is make it so a user can select the 'handle' they use per group with a sensible default of course.</td> </tr> </table> <h2>3&#65039;&#8419; Event management / event registration</h2> <table> </table> <h2>4&#65039;&#8419; Composing/sending emails to members</h2> <table> <tr> <td>bdanin</td> <td>I'm wondering if there has been any work done on this?We're planning to have a system where a custom form will be setup in Drupal with a SendGrid integration, using the drupal/sendgrid_integration module.Regardless of the transactional provider, the thing we're interested in understanding, or will need to build regardless is how to choose "groups" or create groupings of members for email distribution.Along with scheduling of emails.</td> </tr> <tr> <td>jdleonard</td> <td>@bdanin This needs some love: <a href="https://docs.google.com/document/d/1HvoCnBlvU3nvIoQaoIEO3fANCv5y-gLI9o8leexerrw/edit">https://docs.google.com/document/d/1HvoCnBlvU3nvIoQaoIEO3fANCv5y-gLI9o8leexerrw/edit</a></td> </tr> <tr> <td>jdleonard</td> <td>"Segments (Smart Groups in Civi)" refers to the concept of dynamically determining recipients based on some filters.</td> </tr> <tr> <td>bdanin</td> <td>@ebremner FYI</td> </tr> </table> <h2>5&#65039;&#8419; Wireframes / mockups</h2> <table> </table> <h2>6&#65039;&#8419; Documentation</h2> <table> </table> <h2>7&#65039;&#8419; CRM Membership</h2> <table> <tr> <td>mortona2k</td> <td>Check out the refactored Membership: <a href="http://www.drupal.org/project/crm_membership/issues/3583135">www.drupal.org/project/crm_membership/issues/3583135</a>Depends on:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/crm_membership_commerce/issues/3589627" title="Status: Active">#3589627: Update service to use relationship reference</a></span>(I see now that the last one may need more work to fix the tests)</td> </tr> <tr> <td>James Shields</td> <td>I'll take a look at this. I want to get back into contributing to this module, but I don't think I'll get time until June.</td> </tr> </table> <h2>8&#65039;&#8419; CRM (generally)</h2> <table> <tr> <td>Eric (sikofitt)</td> <td>Currently at MidCamp contrib day working on CRM with Steve and Bob.&nbsp; Any suggestions from the community of what should be worked on?</td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/primary_entity_reference/issues/3576123">https://www.drupal.org/project/primary_entity_reference/issues/3576123</a> would plug a hole in CRM's views integration</td> </tr> <tr> <td>jdleonard</td> <td>Lower priority, but in the spirit of fully functional integrations...<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/primary_entity_reference/issues/3559155" title="Status: Active">#3559155: Rules (Typed Data?) support for the primary item</a></span></td> </tr> <tr> <td>jdleonard</td> <td>And[#3559173]</td> </tr> <tr> <td>jdleonard</td> <td>All three are prerequisites for fully supporting the relevant integrations in CRM.</td> </tr> <tr> <td>mortona2k</td> <td>Rules? Not ECA? (edited)</td> </tr> <tr> <td>jdleonard</td> <td>Per <a href="https://www.drupal.org/node/3557691">https://www.drupal.org/node/3557691</a> seemingly no additional action needed for ECA support.</td> </tr> <tr> <td>mortona2k</td> <td>Any advantage with Rules at this point? I haven't touched it since ECA came out.</td> </tr> <tr> <td>jdleonard</td> <td>Not sure, but I wouldn't choose it over ECA. However, Rules 4.x has over 13,000 reported installs. But I think more importantly, this is about typed data support, which is now a core API.</td> </tr> <tr> <td>mortona2k</td> <td>I think I hit an issue with the contact method fields mapped on the user registration/edit form. The widgets have to be saved manually. <a href="https://www.drupal.org/node/add/project-issue/primary_entity_reference">https://www.drupal.org/node/add/project-issue/primary_entity_reference</a></td> </tr> <tr> <td>mortona2k</td> <td>I ran into this reddit post recently. I think building on drupal is a much smarter approach.<a href="https://www.reddit.com/r/CRM/comments/1tbu9cg/can_claude_code_create_a_good_crm/">https://www.reddit.com/r/CRM/comments/1tbu9cg/can_claude_code_create_a_good_crm/</a></td> </tr> <tr> <td>jdleonard</td> <td>Agreed. Looking forward to seeing what people do with it.</td> </tr> </table> <h2>9&#65039;&#8419; Catching up on past meeting notes/recordings</h2> <table> <tr> <td>jdleonard</td> <td>Coming shortly...</td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/member/issues/3578687">https://www.drupal.org/project/member/issues/3578687</a></td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/member/issues/3590152">https://www.drupal.org/project/member/issues/3590152</a></td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/member/issues/3590153">https://www.drupal.org/project/member/issues/3590153</a></td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/member/issues/3577358">https://www.drupal.org/project/member/issues/3577358</a></td> </tr> <tr> <td>jdleonard</td> <td><a href="https://www.drupal.org/project/member/issues/3577359">https://www.drupal.org/project/member/issues/3577359</a></td> </tr> <tr> <td></td> <td><a href="https://www.drupal.org/project/member/issues/3590131">https://www.drupal.org/project/member/issues/3590131</a></td> </tr> <tr> <td></td> <td><a href="https://www.drupal.org/project/member/issues/3590132">https://www.drupal.org/project/member/issues/3590132</a></td> </tr> <tr> <td></td> <td><a href="https://www.drupal.org/project/member/issues/3590133">https://www.drupal.org/project/member/issues/3590133</a></td> </tr> <tr> <td></td> <td>Apologies for the delay in getting these resolved...</td> </tr> <tr> <td></td> <td>If anyone would like to take this over, I would be grateful!</td> </tr> </table> <h2>1&#65039;&#8419;0&#65039;&#8419; Seeking people (technical/non-technical) who want to contribute, but don't know where to start! Please share your interest in Member Platform and I'll follow up with you directly.</h2> <table> </table> <h2>1&#65039;&#8419;1&#65039;&#8419; CRM/Group integration (edited) </h2> <table> <tr> <td>mradamjohn</td> <td>Do I recall correctly you had some code somewhere contrib in this bucket @mortona2k Andrew?</td> </tr> <tr> <td>jdleonard</td> <td>For reference: <a href="https://project.pages.drupalcode.org/crm/group/">https://project.pages.drupalcode.org/crm/group/</a></td> </tr> <tr> <td>mortona2k</td> <td>@mradamjohn it just works! Well, the parts that are currently implemented at least.</td> </tr> <tr> <td>mortona2k</td> <td>Group 4.x alpha was just released. Might be worth making the jump now?</td> </tr> <tr> <td>mortona2k</td> <td>I am planning to use ECA to fill in implementation gaps.</td> </tr> <tr> <td>jdleonard</td> <td>What are the gaps?</td> </tr> <tr> <td>mortona2k</td> <td>I think everything is manual right now. So you would have to create a group and then add the contacts. I want a rule where every company type contact gets a corresponding group.</td> </tr> <tr> <td>mortona2k</td> <td>I just saw this question in the group slack about subgroup implementation and database structure questions. I think it's going to be a similar issue for the transitive relationships we've been working on: Kingdutch in #group-module</td> </tr> <tr> <td>jdleonard</td> <td>@mortona2k Obviously more work for you, but maybe create a "CRM Group Auto Create" contrib module that lets a user, for each contact type, optionally select a group type for a group to be created upon contact creation?</td> </tr> <tr> <td>mortona2k</td> <td>Maybe, if I can't do it with a simple ECA model.</td> </tr> <tr> <td>mradamjohn</td> <td>Or a group organizer select an auto membership based on given criteria (ie domain name of email)...</td> </tr> <tr> <td>mortona2k</td> <td>In the user contact mapping settings, there is a setting for access control, with options for user entity access, or contact entity access. Do we also need group entity access, or is that transferred through the group giving a user access to a contact? (I'll test)</td> </tr> <tr> <td>jdleonard</td> <td>@mortona2k That's for the field mapping, right?</td> </tr> <tr> <td>mortona2k</td> <td>yeah</td> </tr> <tr> <td>jdleonard</td> <td>It's saying that on the user entity form, the field will be exposed and field-level access control will be based on the user's access to the user OR the contact. I'm not sure I see the relevance to group integration. What use case are you solving for?</td> </tr> <tr> <td>mortona2k</td> <td>For example, a company admin should be able to see all the info for employees. Group grants them that permission when they are the group admin and the employee contacts are added.... actually I think that is the answer.</td> </tr> <tr> <td>jdleonard</td> <td>So in the same way that a contact can be mapped to a user, a contact perhaps should also be able to be mapped to a group?</td> </tr> <tr> <td>mortona2k</td> <td>Except it doesn't work. The group admin can see the contact, but can't view/edit their fields.</td> </tr> <tr> <td>jdleonard</td> <td>Do you want the group admin to be granted access to edit the contact entity or the user entity? (field level access is a subsequent question)</td> </tr> <tr> <td>mortona2k</td> <td>yeah</td> </tr> <tr> <td>jdleonard</td> <td>Sorry, to be clear, which: contact or user?</td> </tr> <tr> <td>mortona2k</td> <td>Company admin should be able to create both. Contact if it's just a crm record, or User + Contact if they are adding someone who should be able to log in and see the group.</td> </tr> <tr> <td>mortona2k</td> <td>If adding a User, the Contact should be created and added automatically.</td> </tr> <tr> <td>jdleonard</td> <td>Is "company admin" a group role or a site role?</td> </tr> <tr> <td>mortona2k</td> <td>group</td> </tr> <tr> <td>mortona2k</td> <td>and also a crm relationship</td> </tr> <tr> <td>mortona2k</td> <td>which I may not need both</td> </tr> <tr> <td>jdleonard</td> <td>Is the group to be used for anything other than contact access control?</td> </tr> <tr> <td>freelock</td> <td>Are we talking Group 3, or Group 4? Group 4 recently had an alpha release -- and is the first to use the access policy api in core, instead of contrib flexible_permissions -- do we want to target work for group 4, or support group 3?</td> </tr> <tr> <td>mortona2k</td> <td>Probably should make the jump to group 4 now. However, access policy is very customizable and maybe we don't really need group for this kind of access control? Access to view employee contacts could be granted to contacts that have an admin relationship to the company.I am using group for company administration, like adding employees and changing roles. That could be implemented for just CRM though.We will also need access rules around voting, where a company gets 1 vote, and independent members also get a vote.</td> </tr> <tr> <td>mortona2k</td> <td>Only "user entity access" option works to put the fields on the registration form. May need an exception for that or something.</td> </tr> <tr> <td>jdleonard</td> <td>Group sounds unnecessary for this type of access control, but, if you need to use Group anyway, it's a more site builder friendly way to implement the access control.</td> </tr> <tr> <td>jdleonard</td> <td>Voting is a challenging problem space to generalize solutions for contrib! Use cases vary so widely.</td> </tr> <tr> <td></td> <td>@mortona2k I don't understand your last message.</td> </tr> <tr> <td>mortona2k</td> <td>Granting access to the mapped fields via the contact access doesn&rsquo;t allow anonymous users to see the fields on the registration form.</td> </tr> <tr> <td>jdleonard</td> <td>Do anonymous users have permission to create a contact?</td> </tr> <tr> <td>mortona2k</td> <td>Some group stuff feels redundant but may provide some ui niceties and relevant extensions. Not sure yet, still experimenting.</td> </tr> <tr> <td>mortona2k</td> <td>No, but that seems scary</td> </tr> <tr> <td>jdleonard</td> <td>Agreed. I see the challenge. Feels like there's a feature request in there.</td> </tr> <tr> <td>mortona2k</td> <td>I'm going to look into CRM Case for voting and some other Workflowy features.</td> </tr> <tr> <td>jdleonard</td> <td>Realistically, I think CRM needs to continue to support Group 2/3 for 1.x. It could certainly add support for 4, but an alpha seems early to start chasing that moving target?</td> </tr> <tr> <td>mortona2k</td> <td>I was hoping group 4 would drop in by managing its own access/permissions</td> </tr> <tr> <td>jdleonard</td> <td>I don't know enough to comment more.</td> </tr> <tr> <td>mortona2k</td> <td>I&rsquo;ll report back at the next meeting</td> </tr> <tr> <td>freelock</td> <td>from the sounds of it, the group 4 alpha is pretty solid - haven't tried it yet, but saw a video a couple weeks ago from kristiaan that sounds like he thought it wouldn't be much longer.<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/group/issues/3493574" title="Status: Active">#3493574: [Meta] Roadmap for Group 4.0.0</a></span></td> </tr> </table> <h2>1&#65039;&#8419;2&#65039;&#8419; CRM cases/workflows</h2> <table> <tr> <td>mortona2k</td> <td>We have a need for things that are created and need to pass through various states with different permissions and access for each step. Was recently pointed towards this module: <a href="https://www.drupal.org/project/crm_caseI">https://www.drupal.org/project/crm_caseI</a>'ll be looking into this to support membership voting features and a few other things.</td> </tr> </table>