Contrib.social

Existing Contact - Create New failure after numeric search with locked fields

Open on Drupal.org →
Created on 4 May 2023, about 1 year ago
Updated 18 May 2023, about 1 year ago

1.0 Problem/Motivation

We have a webform with an Existing Contact search field, linked to some contact details. The contact details are locked using the "Fields to lock" section of the Webform tab. The user can unlock these fields by searching for the contact and then pressing "Create New".

If the user enters numeric data in the Existing Contact field and then presses "Create New", the resulting submission doesn't record the contact details, and doesn't create the Contact.

2.0 Detailed steps to reproduce (embed screenshots)

  1. Setup: Drupal 7 with the latest webform and webform_civicrm modules
  2. Create a new webform
  3. Enable CiviCRM processing
  4. Number of contacts: 1
  5. Contact fields enabled: Existing Contact, First Name, Last Name
  6. Switch to the webform tab and edit the Existing Contact field
  7. Display: Form Widget: Autocomplete
  8. Contact Field Handling: Fields to Lock: Name
  9. Contact Field Handling: Locked fields should be: Disabled
  10. Default Value: Set default Contact from: None
  11. Save the component
  12. View Draft
  13. Enter a number into the Existing Contact field (e.g. 6574) and press Create New
  14. Change First Name and Last Name, e.g. to Test Contact
  15. Submit the form
  16. Go back to the form and look at the Results tab
  17. Observe that no data has been recorded

3.0 Proposed resolution

It's possible to work around the issue by selecting "Submit disabled field value(s)" in the Existing Contact webform element settings. That's acceptable for our form where the issue was discovered, but the current behaviour definitely seems to be incorrect. This conditional is incorrectly evaluating TRUE when Existing Contact contains a number, even if that number is not a Contact ID and the user has pressed Create New:

https://github.com/colemanw/webform_civicrm/blob/7.x-5.x/includes/wf_crm...

I've tried a partial fix locally, changing line 2474 to:

      if (!$existing_contact_val[0] || (is_numeric($existing_contact_val[0]) && $this->isExistingContact($existing_contact_val[0]))) {

And adding this function:

  private function isExistingContact($negativeContactID) {
    $contactID = substr($negativeContactID, 1); 
    return (wf_civicrm_api('contact', 'get', ['id' => $contactID]))['count'] > 0;
  }

However, that only checks that the number is a valid Contact ID. It doesn't actually rule out the possibility that the user has pressed Create New and entered data.

Ideally, there would be some reliable way to differentiate between pressing Create New versus pre-filling with an Existing Contact.

🐛 Bug report
Status

Active

Version

5.8

Component

CiviCRM Data Handling

Created by

🇦🇺Australia jude.hungerford

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jude.hungerford
  • Comment about 1 year ago →
    🇦🇺Australia jude.hungerford

    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.

  • Comment about 1 year ago →
    🇦🇺Australia jude.hungerford

    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.

  • Comment about 1 year ago →
    🇦🇺Australia jude.hungerford

    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...

  • Comment about 1 year ago →
    🇦🇺Australia jude.hungerford
contrib.social Blog FAQ Discussions
Production build 0.69.0 2024