Allow mapping to previously created drupal entities on pull based upon mapping "key" field

This is cool.
In this scenario the upsert-to-SF key is the same as the pull-to-Drupal key.

Is there an argument to be made that they should be separable?

Does this work for obvious cases, like user uid and user email?

This patch does work well, however, it causes a strict warning:

Strict warning: Only variables should be passed by reference in salesforce_pull_process_records() (line 345 of /sites/all/modules/contrib/salesforce/modules/salesforce_pull/salesforce_pull.module).

Attached is a patch that makes the error go away.

Also, outside of the scope of the patch above. if you want to pull by email and not username, you can change this in the patch above:

if ($field_mapping['key']) {
  $key_field = $field_mapping['drupal_field']['fieldmap_value'];
  $sf_key_name = $field_mapping['salesforce_field']['name'];
  break;
}

to

if (isset($field_mapping['drupal_field']['fieldmap_value']) &&
    $field_mapping['drupal_field']['fieldmap_value'] == 'mail') {
  $key_field = $field_mapping['drupal_field']['fieldmap_value'];
  $sf_key_name = $field_mapping['salesforce_field']['name'];
  break;
}

As the client we were working on used the email registration module and not every SF record had the Website_Username__c in it. So this patch is great in general, but we had to tweak it some. Just putting thing here if anyone else runs into the issue we had, not 100% sure I want to put the patch unless requested for this use case.

Thank you for your work on the patch.
I have no doubt that some folks will want to apply this functionality.
But, since it's a potentially major change to existing behavior, there are two big things that need to change before this could be committed:

1. Make this more configurable (and extensible).
Allow admins to choose whether or not to match existing entities when pulling.
Allow other modules to alter match criteria at runtime.

2. Don't change existing behavior.
(perhaps by defaulting to the "off" configuration in #1).

This seems related to another issue about externalId and idLookup for matching? https://www.drupal.org/node/1951728

@labboy0276: For your use case, did you set the email field to be the key?

Rerolled.

This appears to be working for me on user entities, it has changed from creating duplicate records for every record that wasn't previously downloaded (would have been all 45k of them) to updating the records. Also, in the mapping definition the email field is set as "key" and it seems to be able to work from that automatically, no extra changes necessary.

Clarified the title.

There should only be one record for each primary key, so to allow more than one is a bug.

I suspect this may be creating a problem I'm seeing - it's trying to create duplicate records in salesforce_mapping_object.

Is this the same issue as https://www.drupal.org/node/2230599?

7.x is no longer supported