This first occurred on a multilingual site, and has since been tested on a local clean install of D7 and CiviCRM 4.6.9 with only required modules (fully updated).

Permanently deleting a CiviCRM contact that was created with webform_CiviCRM leads to contact creation failing (when the form is submitted by an anonymous user) with the following error logged:

The CiviCRM "contact create" API returned the error: "DB Error: constraint violation" when called by function "preSave" on line 143 of wf_crm_webform_postprocess.inc with parameters: "Array ( [contact_type] => Individual [contact_sub_type] => Array ( ) [webform_label] => Contact 1 [first_name] => asdf [last_name] => fff [source] => Test [check_permissions] => [version] => 3 ) "

In the civicrm_log table the “modified_id” field is saved as the previous contact’s ID, which may be a cause/symptom of the issue.

The local install was ported back to a single language site, but the issue remains. Switching on advanced civicrm logging does not fix the issue (at least if it already exists. I didn't test whether a working site with advanced logging suffered the same problem).

See this link for background and a backtrace: http://civicrm.stackexchange.com/questions/6820/webform-civicrm-not-crea...

Comments

btc97 created an issue. See original summary.

btc97’s picture

btc97 commented
Issue summary: View changes
bcobin’s picture

bcobin commented

This would explain a lot. The first thing I do when I create a site that uses this functionality is to test the form workflow with a dummy contact, which I'll then delete.

Great catch here - hoping for a solution… thanks!

colemanw’s picture

colemanw commented
Status: Active » Needs review

So I think this is the fix: https://github.com/colemanw/webform_civicrm/pull/21

Particularly the first commit (the second is mostly cleanup and a not-really-related fix for advanced logging).

In my testing, setting that session variable caused the bug, and it was unnecessary; "simple" logging works fine without it (might have been an issue in older versions of Civi, but anyway it's fixed now).

However, I'm not sure what to do to fix broken sites where the session variable has already been set. Manually unset it? Wait for it to expire? I don't know what the expiration time is, but if it was reasonably small then maybe no further action is needed? Does anyone know? I was kind of surprised to find that (without the patch) the bug persisted even when I tried on a different private browser window. Not really sure why the session persists across multiple anonymous users.

btc97’s picture

btc97 commented

Coleman you are a star! That fix has squashed the bug dead on my local test (single language) and dev (multilingual) sites. How incredibly satisfying!

It looks like the CiviCRM session variable is stored in Drupal's sessions table. Expiration time is set in settings.php, and the Drupal default seems to be 200000s or a bit over 2 days. Just truncating the table sorted the issue for me immediately.

Thanks for all your work on webform_civicrm—it's such a fantastic feature, and I can't imagine using CiviCRM now without it!

colemanw’s picture

colemanw commented
Status: Needs review » Reviewed & tested by the community

Great thanks for investigating that. Sounds like just letting it expire will work fine.

  • colemanw committed 5375d46 on 7.x-4.x 
    Merge pull request #21 from colemanw/logging

Issue #2592827 - Fix...
  • colemanw committed 636448d on 7.x-4.x
    Issue #2592827 - Remove unnecessary session variable
colemanw’s picture

colemanw commented
Status: Reviewed & tested by the community » Fixed
welly’s picture

welly commented

This appears to be working (thank you!), however I am still getting an error logged in watchdog:

The CiviCRM "uf_match getsingle" API returned the error: "Expected one UFMatch but found 0" when called by function "saveContactLocation" on line 746 of wf_crm_webform_postprocess.inc with parameters: "Array ( [contact_id] => 3034 [domain_id] => 1 [check_permissions] => [version] => 3 ) "

Any thoughts? Nothing seems to be out of order and the contact is being created correctly.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

jkingsnorth’s picture

jkingsnorth commented

I've opened a separate issue for the uf_match getsingle problem here: #2613950: uf_match getsingle error for saveContactLocation