jude.hungerford → created an issue.
I notice that the project page no longer has a version available for D9 or D10:
https://www.drupal.org/project/civimenu →
This means the Drupal installation considers it a security risk, and sends regular emails to prompt me to update or remove the module.
Also, the CiviCRM menu is no longer appearing on Drupal pages. I've just tested it on a clean install of Drupal 10.2.3 with CiviCRM 5.70.0. It's also not working on our dev site with Drupal 10.2.2 and CiviCRM 5.69.3.
Please let me know if I should open a new issue (or two). I'm posting here for now since it relates to Drupal 10 compatibility.
jude.hungerford → created an issue.
I've tested !5321 on Drupal 10.1.5, and I can confirm that the patch applies cleanly and it fixes our View with an "Is none of" filter.
Yes, I've tested this change and confirmed that the results are correct.
Thank you!
Yes, this is correct and confirmed working. Thank you!
jude.hungerford → created an issue.
jude.hungerford → created an issue.
Done!
https://github.com/colemanw/webform_civicrm/pull/902
That page says that it passed all checks, though I also got an email saying it failed on "Drupal 9.5.* | CiviCRM 5.65.x-dev".
I tried manually updating HandlerBase.php and ManyToOneAdapter.php in Drupal 9.5.9, based on this merge request:
https://git.drupalcode.org/project/drupal/-/merge_requests/1624/diffs#no...
I can confirm that Views with "Is none of" filters work after this patch. Without it, the View returns a white screen with the text "The website encountered an unexpected error. Please try again later".
jude.hungerford → created an issue.
Sorry, I've referred to the wrong line in my original comment. It's actually line 2474 which I'm changing locally (also edited above for clarity):
https://github.com/colemanw/webform_civicrm/blob/7.x-5.x/includes/wf_crm...
In place of the code I've suggested above, I think line 2478 can be changed to:
if (!$existing_contact_val[0] || ((is_numeric($existing_contact_val[0]) && ((int)$existing_contact_val[0] > 0)))) {
If they've selected an actual contact, $existing_contact_val[0] will be positive, whereas if they enter numeric data and press Create New, it will be negative. This might be an acceptable way to differentiate between the two scenarios, though I don't understand enough to be very confident that it's correct.
I've discovered an issue with the workaround I've suggested above. When "Submit disabled field value(s)" is enabled, the Contact's name is blanked (in the database) after selecting an existing contact and submitting the form.
Same form setup as described above
Search for an existing contact in the Existing Contact field
Select an existing contact
Submit the form
Observe that the Contact now has blanks for First name and Last name
So it's not a good workaround, as it causes a different issue.
jude.hungerford → created an issue.
Hi @jitendrapurohit, thank you for providing the fix!
I've just tested it, and I can confirm that it fixes the issue after I remove and re-add the custom fields.
We have quite a few webforms with custom fields arranged in layout boxes and other configuration which would take some time to remove and recreate. I see that the yaml changes are quite small, so it's probably easier to fix them with manual edits, or maybe it can be automated. I'll look into the options there, but for future webforms, this change does fix the problem.
This pull request seems to address a very similar issue:
https://github.com/colemanw/webform_civicrm/pull/800/files#diff-1bee4e56...
I had hoped that it might fix this as well, but it doesn't. The symptom is the same, but in a different context: this one is submitting the default value for custom fields, not the value chosen.
Hi @jitendrapurohit, I've tested the patch on a clone of our system, and I can confirm that it solves the issue. Thank you!
jude.hungerford → created an issue.