3

Since upgrading from 4.4->4.6 we're having issues with on-behalf-of membership signups. It is very common for our use-case to have people create both an Individual and and Organization with the same name and email address. We're finding that in the process of a membership signup where a person creates both these things, the individual is created during the drupal user creation, but then when the Org should be created it instead overwrites the previous Individual and changes its type but leaves the Organization Name field blank.

What I would really love in the short term is to be able to turn off unsupervised deduping entirely, but I can't find a way to. Simply deleting the unsupervised rule for individuals causes the user-creation step to barf an error that no unsupervised rule exists, but I can't find a way to just turn it off until I can find a better solution.

  • is it the same outcome if the Contribution page has OnBehalfOf set to Optional v Required – petednz - fuzion Mar 22 '16 at 18:46
  • also which 4.6 are you on? – petednz - fuzion Mar 22 '16 at 18:47
  • @petednz-fuzion For our use-case, it has to be "required" as individuals never hold membership directly, only by inheritance from an organization. We're running CiviCRM 4.6.14, recently upgraded from 4.4.20. – Sean MacGillivray Mar 23 '16 at 13:00
  • I wonder if this is related: link – Sean MacGillivray Mar 23 '16 at 14:52
  • the reason i asked if you could confirm if it happened on either option or only required was to help figure if it was similar issue or different – petednz - fuzion Mar 23 '16 at 18:49
3

Either change the unsupervised dedupe rule or create a new one where the conditions can't be met. So change the "Weight Threshold to Consider Contacts 'Matching':" number to something higher than the conditions can add up to. That way it's never met, so it isn't applied.

You didn't ask for help on the underlying problem but it sounds like for some reason it isn't first matching on the contact type. You might also be able to up the threshold. I think the default unsupervised rule or organization has 10 for name and 10 for email but only needs 10 to pass so if either the name or email matches it says it's a match. Maybe if you make the match 20.

  • I've reduced the fields for both Orgs and Individuals to just Email, gave email a weight of 10 and gave the rule a threshold of 50 and the problem persists. I even deleted the reserved General rules for individuals. – Sean MacGillivray Mar 22 '16 at 17:08
1

I think I've got a temp solution for this. Further testing suggested that there was some logic matching the on-behalf contact by display_name; the issue only persists if the individual contact's display_name was the same as the org that got created in the membership signup.

I diffed my version of the file (4.6.14) against a more recent version (4.7.3) and found this change in the logic:

 // if onbehalf-of-organization
-    if (!empty($this->_params['hidden_onbehalf_profile'])) {
+    if (!empty($this->_values['onbehalf_profile_id']) && !empty($this->_params['onbehalf']['organization_name'])) {
       // CRM-15182
-      if (empty($this->_params['org_option']) && empty($this->_params['organization_id'])) {
-        if (!empty($this->_params['onbehalfof_id'])) {
-          $this->_params['organization_id'] = $this->_params['onbehalfof_id'];
-        }
-        else {
-          $this->_params['organization_id'] = CRM_Core_DAO::getFieldValue('CRM_Contact_DAO_Contact', $this->_params['onbehalf']['organization_name'], 'id', 'display_name');
-        }
-      }
+      $this->_params['organization_id'] = CRM_Core_DAO::getFieldValue('CRM_Contact_DAO_Contact', $this->_params['onbehalf']['organization_name'], 'id', 'display_name');

I applied this change to my version of the file and the issue appears to be resolved. Long-term fix looks like a 4.6.14->4.7.3 or .4 upgrade. Thanks @petednz-fuzion for your help!

  • ah right. so if there were multiple contacts with same name it would have been finding the one with the lowest ID regardless of what Contact Type they were. – petednz - fuzion Mar 28 '16 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.