@bluegeek9 I disagree. The motivation here isn't about advocacy or increasing familiarity, but rather about pursuing inclusion, as commonly practiced in the Drupal community.
Someone who uses gender-neutral pronouns installing Name Field and finding their pronouns not being part of the default set is clearly not being included by the Drupal community.
Someone using a site with the Name Field default pronouns (which will typically remain unchanged by the developer / site builder) may be required to choose from a gendered pronoun, which is not being included by whatever that community is.
As you say, defaults can be changed by a site builder. If a site builder wishes to make the set of default pronouns less inclusive, they certainly can, but we should endeavor to have the defaults be inclusive.
What harm can come from being more inclusive here?
The CRM project requires a new release of Name Field for CRM to produce a beta release.
Steve says this will be fixed by the end of the day
James Shields (lostcarpark) can try to address the outstanding visual issue once bluegeek9 pushes his code
Closing in favor of 🐛 Submitting a Blank Person Contact causes a "Argument #1 ($text) must be of type string, null given" error Active
Steve to figure out whether this belongs in the CRM project or as a separate project.
This feels possibly worthy of being a beta blocker.
Per discussion with @bluegeek9, I begrudgingly accept Option B. Primary Entity Reference needs some more eyeballs and tests and we need to adopt it for CRM.
jdleonard → created an issue.
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:
- composer create-project drupal/recommended-project my-site && cd my-site
- composer config minimum-stability alpha
- composer require 'drupal/crm:^1.0.0-alpha5'
- composer require drush/drush
- ddev config --project-type=drupal --docroot=web --php-version=8.3
- ddev start
- ddev drush site:install -y
- ddev drush pm:install crm -y
- ddev drush user:login
I also tried:
- composer create-project drupal/recommended-project my-site && cd my-site
- composer config minimum-stability alpha
- composer require 'drupal/crm:^1.0.0-alpha5'
- ddev config --project-type=drupal --docroot=web --php-version=8.3
- ddev start
- Ran install with Standard profile via https://my-site.ddev.site/core/install.php
- Enabled CRM via https://my-site.ddev.site/admin/modules
Could you please:
- Try reproducing using either of the above sets of steps
- 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.