🇺🇸United States @jdleonard

Adding bee low to issue summary.

When there are errors and AJAX involved, sometimes weird stuff happens. I don't think that's something that CRM can reasonably control. But certainly any bug that's caused by CRM should have an issue filed.

I'll echo @bluegeek9 that potential bugs should be verified against the latest dev branch (note that's what the Version field's "1.0.x-dev" value represents) prior to being created as an issue. This allows maintainers to focus on actionable issues.

Setting status to reflect that this can't be reproduced in the latest dev branch.

This is now working. Maddeningly time consuming to figure out what the problem was. Placeholder variable needed to start with @ rather than % so as to not introduce HTML into the button label, which was silently causing a no-op.

jdleonard → created an issue.

I like the idea of following an existing pattern. However, a key difference here with adding a taxonomy term is that from the list of taxonomy terms, there is one button to get back to the term add form whereas for contacts, the button takes you to `/crm/contact/add`, which then requires you to make another selection (a bundle).

I agree with @speckles that creating contact after contact will be a common pattern and is worth optimizing for. The two additional buttons optimize for the sub-scenarios of 1) creating another Contact of the same type; and 2) creating another Contact of a different type.

Sub-scenario 2 could perhaps be eliminated if the contact add form were to provide a way to create an associated contact e.g. while creating a Person, create an Organization with a corresponding Relationship (I would think that creating a related Contact would be the most common cause of sub-scenario 2), but there's much more complexity there so I'd propose deferring consideration of that.

Changing IS and title to reflect my proposed solution (but seeking input from @speckles too).

This is mostly working.

I haven't quite figured out whether the pages-preview job is doing anything productive.

And I can't fully test this until it's merged, due to conditional logic about the context in which it is executed.

See https://git.drupalcode.org/issue/crm-3527319/-/jobs/6258897

jdleonard → created an issue.

Created a draft MR to add those buttons. Both buttons were working for me, but now only one of them is and I can't figure out why. Could use some fresh eyes!

I feel like the status message could get overwhelming if it includes links for each Contact Type.

What if we added two buttons to the Contact add form?

• "Save and add another [Type]" -> /crm/contact/add/[type]
• "Save and add another Contact" -> /crm/contact/add

Yes, I think tagging could be optional. I think we should probably have a more robust discussion about criteria for what functionality is required vs. optional (ships with CRM project) vs. separate project and how recipes fit in.

I agree.

I'm new to `persist_with_no_fields`. Would it cause artifacts to remain after uninstalling CRM?

Hi @marco.b!

I failed to reproduce this on a clean install.

I tried as follows:

1. composer create-project drupal/recommended-project my-site && cd my-site
2. composer config minimum-stability alpha
3. composer require 'drupal/crm:^1.0.0-alpha5'
4. composer require drush/drush
5. ddev config --project-type=drupal --docroot=web --php-version=8.3
6. ddev start
7. ddev drush site:install -y
8. ddev drush pm:install crm -y
9. ddev drush user:login

I also tried:

1. composer create-project drupal/recommended-project my-site && cd my-site
2. composer config minimum-stability alpha
3. composer require 'drupal/crm:^1.0.0-alpha5'
4. ddev config --project-type=drupal --docroot=web --php-version=8.3
5. ddev start
6. Ran install with Standard profile via https://my-site.ddev.site/core/install.php
7. Enabled CRM via https://my-site.ddev.site/admin/modules

Could you please:

1. Try reproducing using either of the above sets of steps
2. If that works, provide a copy of your composer.json (I suspect the issue might be caused by or related to another project) and details of your hosting environment

Thanks @speckles! The current set up instructions are definitely barebones and developer-oriented. Separate from this issue about smoke testing, I'd suggest that you create a new issue "Document installation and configuration for novice users" where you create an issue fork and propose new/updated pages in docs/ as needed.

nicxvan → credited jdleonard → .

Re-opening assigned to me so I can flesh this out.

jdleonard → created an issue.

Only lightly tested. The code makes more sense to me this way.

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

My use case for this is working with merge requests in PhpStorm.

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

seantwalsh → credited jdleonard → .

jdleonard → created an issue.

nicxvan → credited jdleonard → .

nicxvan → credited jdleonard → .

Added Fathom specific steps for Zoom meeting host.

jdleonard → created an issue.

I would imagine translation would be difficult to languages where there is no established gender-neutral titles. https://en.wikipedia.org/wiki/Gender-neutral_title#Languages lists examples in Japanese and Thai. Unless the Name module is shipping translations, I think we can defer to the consumers of the module to translate or remove any titles they don't wish to use.

I did run the concept of this issue by #diversity-inclusion in Drupal Slack.

Among other gems, Fei wrote:

Because we do still use titles in many settings, I would argue that it's important to have one or two common gender-neutral options OOTB. This is because every single time we are exposed to an unfamiliar thing, it becomes more comfortable. So it's an opportunity to bolster visibility among audiences who may not have much exposure to the concept of gender non-conformance.

Further enhancements would be to provide a "do not use title" option (selectable by someone filling out a form exposing the title sub-field) and a write-in option for the title, but I wanted to keep the scope of this change small to facilitate greater inclusion ASAP, especially for consumers of the module that just leave the default set of provided titles as-is. These enhancements could be follow-up issues, but I mention them for context.

Clarified that link to Drupal Core calendar might default to visitor's timezone. Seemingly depending on logged in state (and likely other factors), the link doesn't reliably show in my timezone even when my Google Calendar's timezone matches that of my computer). Adjusted to meet character limit. And converted semicolon to period to reflect more common reading level.

seantwalsh → credited jdleonard → .

seantwalsh → credited jdleonard → .

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

nicxvan → credited jdleonard → .

jdleonard → created an issue.

jdleonard → created an issue.

jdleonard → created an issue.

For Member Platform, there was discussion of providing the ability to set each (Contact/Person) field as required/optional/hidden for each of A) user registering; B) user filling out a secondary registration form; and C) user editing their (Contact) profile. For editing, perhaps required/optional/disabled/hidden.

The "Secondary registration form" idea is about prompting the member for additional information after they provide the minimum information during registration. For example, only require email address for initial registration, but, once that's captured (and possibly after email is verified), require additional fields (e.g. name) to complete registration.

This would facilitate, for example, asking a member "What do you expect to get by joining this group?" during (secondary?) registration, but not exposing it to them thereafter. Or not letting them edit their name after registration.

jdleonard → created an issue.

A quick search suggests that Notes is a pretty standard name for this in other CRMs. I think Notes is better in part because it isn't a Drupalism. We should be optimizing the UX for a general user, not a Drupaler. While we could have the machine name be "comments" and the label be "Notes", I think that introduces more confusion than it solves for.

"John Daniel" is my first name.

As someone who goes by a name ("JD") other than his legal name, I am used to setting my "preferred name" to "JD" when the capability exists. Are you proposing that my Contact record would have "JD" in both "Preferred Name" and "Alternative Name"?

Lightly researching, it is becoming clear to me that there are diversity, equity, and inclusion considerations for the naming of name fields and how they are presented. We should run a more final plan by #diversity-inclusion in Drupal Slack for feedback.

The goal is not clear to me. Is there a specific workflow you are seeking to provide? Or is the idea to provide a starting place for a site builder to customize / create workflows

See also: https://www.drupal.org/project/workflows_field →

jdleonard → created an issue.

You mean start by removing the website field and have a follow up to add a contrib field? Fine with me.

That makes sense. I assume delta 0 would be Contact A, delta 1 would be Contact B, and the corresponding label fields would remain?

DetailType is architecturally elegant, but complicates the UX and implementation.

Can we identify possible additional Contact Detail bundles for which a DetailType would make sense?

Is there a strong argument for different Contact Detail bundles sharing the same type entity?

IMO the most flexible and powerful tagging system would allow a site builder to manage multiple vocabularies for tagging, including to which entity types and bundles each can apply. This idea is only half-baked...

There could also be one default vocabulary (for each entity type?) for tags that don't require additional context/grouping that could support free-tagging. I'm not convinced it would be best to use Drupal's built-in concept of vocabulary (probably doesn't need to be fieldable, revisionable, or mixed in with the various non-CRM tag vocabs).

I'm also thinking of mutually exclusive labels e.g. GitLab's Scoped Labels.

Examples that a site builder might create:
"Lead source" vocab that applies to Contacts of type Organization
"VIP" term in the default vocab that applies to Contacts of type Person (note that this introduces the concept of specific terms applying to only certain entities/bundles
"Industry" vocab that applies to Contacts of type Organization or Person
"Eldest" term in the default vocab that applies to Relationships of type Household Member
"Past" term in the default vocab that applies to Relationships (assuming CRM doesn't provide an OOTB way to track this)
"No longer valid" term in the default vocab that applies to Contact Details (though I think CRM should provide a semantic field for this)
"Type" vocab that applies to Contacts of type Organization (e.g. "non-profit")

Probably worth some discussion whether a (non-dev) dependency like Tagify be adopted by CRM. Alternatively there could be a more opinionated, dependency-heavy "CRM Starter" kit that adds these sorts of things, leaving CRM itself very low dependency. Feels like an overall policy would be helpful so that each such thing doesn't require a bespoke debate.

Looking good!

Could you clarify your last comment? It works for Paragraphs, doesn't it?

Why direct? Wouldn't that restrict CRM to SQL backends?

I would assume that entity validation would be the only way to prevent ECA actions from being naughty.

I see the challenge with merging. IIRC there's a way to bypass entity constraints. If that's the case (do you know?), I think entity validation is the way to go.

Sorry, my previous question was unclear. I now get what we're doing here. This addresses my concern about creating Views showing a Contact's relationships so long as the table can be relied upon to be up-to-date. The term "cache" implies to me that it can't. Assuming that this table is always updated whenever relationships are added/removed/updated, I think it might make sense to find a name without "cache".

I don't think it's necessary to add the bundle name. A given Contact is unlikely to have a ton of Relationships so an extra join from this table to the Relationships table to filter by Relationship Type won't be too onerous. However, I'm not opposed to including it and, eventually, performance testing might suggest doing so.

Given the apparent need for this table, I wonder whether it would make sense to revisit the concept of one Relationship entity per direction of the relationship. Only because it would eliminate the need for this table.