CiviCRM Community Forums (archive)

Hi,

I ran into this problem after upgrading a Drupal 7 site from 4.0.7 to 4.3.5 . Not a multi-site. The site has customisations but I replicated the problem with all customisations disabled.

Scenario: existing Drupal user, existing Civi contact with matching email. I deleted civicrm_uf_match records because the Civi database had been copied from a live environment to a test environment where some of the Drupal users did not coincide.

What I did:
Logged in as the Drupal user mentioned above.

Expected behaviour:
The existing Drupal user is matched to the existing Civi contact on email. A civicrm_uf_match record is created to link them.

Actual behaviour:
The existing Drupal user is not matched to the existing Civi contact, instead a new contact is created. A civicrm_uf_match record is created to link the user to the new contact.

I tracked down the cause...

civicrm_user_login() calls:
  return CRM_Core_BAO_UFMatch::synchronize($user, FALSE, 'Drupal',
    civicrm_get_ctype('Individual')
  );

CRM_Core_BAO_UFMatch::synchronize() calls CRM_Core_BAO_UFMatch::synchronizeUFMatch()

CRM_Core_BAO_UFMatch::synchronizeUFMatch() finds no existing civicrm_uf_match record and runs the following code...

      if (!empty($_POST) && !$isLogin) {
        $params = $_POST;
        $params['email'] = $uniqId;

        $dedupeParams = CRM_Dedupe_Finder::formatParams($params, 'Individual');
        $dedupeParams['check_permission'] = FALSE;
        $ids = CRM_Dedupe_Finder::dupesByParams($dedupeParams, 'Individual');
dupesByParams() returns nothing. Because $dedupeParams contains:

Array
(
    [civicrm_address] => Array
        (
            [name] => some-username
        )

    [civicrm_email] => Array
        (
            [email] => some@e.mail
        )

    [civicrm_im] => Array
        (
            [name] => some-username
        )

    [check_permission] =>
)

Hang on, why are civicrm_address and civicrm_im there and why do they contain the username? It look like CRM_Dedupe_Finder::formatParams() iterates through CRM_Dedupe_BAO_RuleGroup::supportedFields(), including tables civicrm_address and civicrm_im, and because $_POST contains field 'name' (Drupal username) and those two tables contain a 'name' field, the username is interpreted as being both an address name and an IM name. :-(

If you're thinking, "ah, but this is a login, so $isLogin will be true, so this code won't run" - that's what I assumed at first, but $isLogin is actually false. It's passed through to CRM_Core_BAO_UFMatch::synchronizeUFMatch() from CRM_Core_BAO_UFMatch::synchronize() , where it defaults to FALSE.

The call to CRM_Core_BAO_UFMatch::synchronize() from civicrm_user_login() does not specify the $isLogin parameter. Amending the call in civicrm_user_login() to:

  return CRM_Core_BAO_UFMatch::synchronize($user, FALSE, 'Drupal',
    civicrm_get_ctype('Individual'), TRUE
  );

fixed the problem, because this bypasses the CRM_Dedupe_Finder::dupesByParams() route and instead does a good old-fashioned CRM_Contact_BAO_Contact::matchContactOnEmail().

Does this seem the right solution - should $isLogin be TRUE here and so using CRM_Contact_BAO_Contact::matchContactOnEmail() ?

Cheers,

Dave

If you are looking at that code & have the impression that some variables mean different things then their name suggests then be bold & rename them as my recollection of that function was that it was hard going & some variables seemed to be misnamed

I wonder it it will help with our disappearing contributions. The CMS User code in profile form is one of the few places that silently rolls back transactions - it could be stumbling on this...

https://github.com/eileenmcnaughton/civicrm-core/commit/f0672563cbc6dae168d7a339817911fe25f66b09