I have created and enabled a civicrm enabled webform which worked perfectly ... until it stopped.

The civicrm webform creates several contacts, establishes relations, populates custom data fields and address fields, and registers the first contact for an event.

After "breaking", it only creates one user, only populates a few of the contact data fields, doesn't create the relationship nor register for the event. In the drupal db log, I find this:

The CiviCRM "contact create" API function returned the error: "DB Error: constraint violation" when called by line 123 of webform_civicrm_utils.inc with the following parameters: "Array ( [contact_type] => Individual [contact_sub_type] => Student [first_name] => Justin [middle_name] => Jeremy [last_name] => Earlioni [nick_name] => jj [gender_id] => 2 [birth_date] => 19961104 [contact_id] => [source] => Student Application [check_permissions] => [version] => 3 ) "

I cannot for the life of me figure out why this has stopped working. Other civicrm webforms, which also do a lot of 'stuff' are still working fine.

I am thinking this is a small issue somewhere, but can't figure out where- any ideas?

Comments

colemanw’s picture

colemanw commented

I believe the empty contact_id param is the key to this problem. That would cause a DB constraint error.
Was Justin a new contact to be created from an anonymous submission? Or was he a logged-in or otherwise known contact to be updated?

jimurl’s picture

jimurl commented

Justin was a new contact. I have enabled the "Contact ID" (hidden) field-not sure if that matters. The form is submitted anonymously.

jimurl’s picture

jimurl commented

Progress: it is totally due to the anonymous submission. I tried submitting the form both anonymously and as a logged in user; the first time it failed and the second time it worked fine. This was for the case where I was creating new contacts with the submission (as determined by the dedupe rule).

Updating existing contacts works fine when the form is submitted by anonymous users. So it seems I have a permission problem.

Thanks for leading me toward the root of the problem. Any ideas what drupal permissions, or civicrm acls, should allow this to work?

colemanw’s picture

colemanw commented

That was a great hint in #2 -- that was the problem exactly -- the contact_id field was getting merged into the contact params.
This fixes it:

diff --git a/webform_civicrm_utils.inc b/webform_civicrm_utils.inc
index 649b8ce..3b58362 100644
--- a/webform_civicrm_utils.inc
+++ b/webform_civicrm_utils.inc
@@ -120,6 +120,7 @@ function webform_civicrm_process_submission($node, &$submission, $op) {
       }
       // Create new contact
       if (empty($id['cid'][$c])) {
+        unset($params['contact_id']);
         $params['source'] = $settings['new_contact_source'];
         $result = webform_civicrm_api('contact', 'create', $params);
         if (!empty($result['id'])) {

I've committed that fix to both branches.

One thing I don't get -- this shouldn't be happening if you are using the latest version, because it doesn't allow empty values to be passed as params for unknown contacts. Perhaps your dev is from a few weeks back?

jimurl’s picture

jimurl commented

The version I was using was from November 1. I see now that 2.2 was released a week later. I'll upgrade to that.

Wow, Coleman, thanks for fixing that. I was starting to delve into some permissions, thinking that was the problem, but was getting nowhere.

colemanw’s picture

colemanw commented
Status: Active » Fixed

Version 2.2 should fix it (although the fix I just committed to dev is even more foolproof). If not please let me know.

jimurl’s picture

jimurl commented

Well, not yet, but here is some more information that could help debug it:

I installed the 2.2 version, and also implemented that patch (well, just manually stuck in unset( $cid...) ).

It still created just the partial record- no relationships, no event participant, etc.

So I tried using the API explorer to insert the record, with all the exact same fields that were mentioned in the watchdog log- including check_permissions= (nothing). It worked, didn't complain, and there were no errors in the log. So it would seem the two api calls are not happening in the same way- one produces an error, the other not.

So, then, I submitted the webform with the information about known existing contacts- making sure the firstname, lastname, and email fields for the contacts were equal, so as to trigger the dedupe rules. All the contact data was inserted correctly, relationships, events all A-OK. But in the watchdog log, same errors! But everything was inserted/ created correctly.

So the error in the watchdog is unrelated to the contact information not getting inserted properly. Two separate things. I submitted the form again, as an authenticated user (with no particular permissions), and found that there were no watchdog errors.

The errors in the watchdog log aren't a problem for me, since the information is getting added regardless; but this problem where the new contact is not being created properly is hard.

colemanw’s picture

colemanw commented

The only difference between an api call by this module and an api call from the explorer is the permissions of the acting user.
But I'm afraid you've lost me with those test results. It doesn't make a lot of sense to me. Could you either test systematically and give results for logged-in, logged-out, updating anonymous & creating anonymous... or give me access to your server so I can test?
Thanks.

jimurl’s picture

jimurl commented

Sorry about the confusing barrage there. I'll try and be more clear.

It turns out, it appears that the failure to fully create and populate the contact record isn't a webform civicrm problem. I was trying to use a custom module to create a drupal user linked to the contact record, ( discussed here: http://drupal.org/node/1162338 ) and to do this, I was doing many, many test submissions. When other anonymous users submitted the form, their contact records were created properly.

The errors in the db log (original subject of this issue) were unrelated to that, but were related to anonymous users submitting the webform. ( No error was logged for authenticated users.)

I hope that expresses my test results clearly.

Status: Fixed » Closed (fixed)

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