Answers.Body: <p>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. </p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T17:08:23.337Z
Answers.Text: 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.
Answers.UserDisplayName: Sean MacGillivray
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T16:05:49.510Z
Answers.LastActivityDate: 2016-03-22T16:05:49.510Z
Answers.UserDisplayName: Paul-Tahoe
Answers.Body: <p>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. </p>
  
  <p>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:</p>
  
  <pre><code> // if onbehalf-of-organization
  -    if (!empty($this-&gt;_params['hidden_onbehalf_profile'])) {
  +    if (!empty($this-&gt;_values['onbehalf_profile_id']) &amp;&amp; !empty($this-&gt;_params['onbehalf']['organization_name'])) {
         // CRM-15182
  -      if (empty($this-&gt;_params['org_option']) &amp;&amp; empty($this-&gt;_params['organization_id'])) {
  -        if (!empty($this-&gt;_params['onbehalfof_id'])) {
  -          $this-&gt;_params['organization_id'] = $this-&gt;_params['onbehalfof_id'];
  -        }
  -        else {
  -          $this-&gt;_params['organization_id'] = CRM_Core_DAO::getFieldValue('CRM_Contact_DAO_Contact', $this-&gt;_params['onbehalf']['organization_name'], 'id', 'display_name');
  -        }
  -      }
  +      $this-&gt;_params['organization_id'] = CRM_Core_DAO::getFieldValue('CRM_Contact_DAO_Contact', $this-&gt;_params['onbehalf']['organization_name'], 'id', 'display_name');
  </code></pre>
  
  <p>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!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-28T22:58:11.397Z
Answers.Text: 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.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-28T19:19:15.210Z
Answers.LastActivityDate: 2016-03-28T19:19:15.210Z
Answers.UserDisplayName: Sean MacGillivray
Body: <p>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. </p>
  
  <p>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. </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T18:46:00.700Z
Comments.Text: is it the same outcome if the Contribution page has OnBehalfOf set to Optional v Required
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-22T18:47:06.777Z
Comments.Text: also which 4.6 are you on?
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-23T13:00:10.770Z
Comments.Text: @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.
Comments.UserDisplayName: Sean MacGillivray
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-23T14:52:33.510Z
Comments.Text: I wonder if this is related: [link](http://civicrm.stackexchange.com/questions/10169/dedupe-rule-for-organization-always-firing-on-membership-signup-form?rq=1)
Comments.UserDisplayName: Sean MacGillivray
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-23T18:49:03.193Z
Comments.Text: 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
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-24T19:09:11.160Z
Comments.Text: @petednz-fuzion gotcha! I set the contribution page to "optional", and when testing I selected the option to contribute on behalf of an org and the same thing happened; the individual contact was overwritten as an Organization.
Comments.UserDisplayName: Sean MacGillivray
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-24T19:10:39.717Z
Comments.Text: If it's pertinent, there is a similar issue with renewals. The individual gets overwritten as an org and this is the contact that is the primary holder of the membership, not the org as it should be. Seems like maybe there's hard-coded deduping that is contact-type-ambiguous?
Comments.UserDisplayName: Sean MacGillivray
Tags: <duplicate-contacts>
Title: Turn deduping off?
ThreadText: # Turn deduping off?
  
  (Asked by: username_0 on 2016-03-22)
  
  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.
  
  **Tags:** duplicate-contacts
  
  > **Comments:**
  > **username_1**: is it the same outcome if the Contribution page has OnBehalfOf set to Optional v Required  
  > **username_1**: also which 4.6 are you on?  
  > **username_0**: @username_1 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.  
  > **username_0**: I wonder if this is related: [link](http://civicrm.stackexchange.com/questions/10169/dedupe-rule-for-organization-always-firing-on-membership-signup-form?rq=1)  
  > **username_1**: 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  
  > **username_0**: @username_1 gotcha! I set the contribution page to "optional", and when testing I selected the option to contribute on behalf of an org and the same thing happened; the individual contact was overwritten as an Organization.  
  > **username_0**: If it's pertinent, there is a similar issue with renewals. The individual gets overwritten as an org and this is the contact that is the primary holder of the membership, not the org as it should be. Seems like maybe there's hard-coded deduping that is contact-type-ambiguous?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2016-03-22. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_0 on 2016-03-28. Score: 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 @username_1 for your help!
  
  > **Comments:**
  > **username_1**: 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.  
  
  ---
  
  