UF match fails on login if no existing civicrm_uf_match record

[davej]

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...

Code: [Select]

      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

[Donald Lobo]

sounds about right I suspect the isLogin came about later and some code was not updated downstream

can you please file an issue and PR for this for 4.4

while you are at it, would be great if you add a few more phpdoc comments to the synchronize functions detailing the parameters

thanx

lobo

[Eileen]

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

[davej]

I've created http://issues.civicrm.org/jira/browse/CRM-13401 and added a patch for the functional change & another adding comments to document parameters & renaming $uniqId to $email in synchronize() & synchronizeUFMatch().

Cheers,

Dave

[Eileen]

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