Salesforce Location Integration

A version of this, along with location cck, date cck, and better generic cck support, was committed to the new sf_contrib module in this package.

http://drupal.org/cvs?commit=372634

Reopening this. I've got this setup and for some reason I can't get City, State and Zip to map to Salesforce. I have all of the data in my object in Salesforce but when I try and map it doesn't come over to Drupal. What's strange is the City will come when I click the "import from Salesforce" on the node, but when I click refresh it disappears. The other strange thing is that the Zip Code field from Salesforce doesn't even show under the "Zip Code" column on the Salesforce tab of each node. Really weird stuff going on here. Module info:

Drupal: 6.20
MySQL: 5.0.92
PHP: 5.3.3
Salesforce Suite: 6.x-2.x-dev (2011-Mar-07)
Location: 6.x-3.1 (also tried 6.x-dev with the same results)

I'm working with this, too, and also having trouble. The basic problem seems to be that the sf_contrib.module's _sf_contrib_import_location() and _sf_user_import_location() functions aren't returning an array of changes. This was both causing an un-handled error in sf_user.module's sf_user_import() (though I believe this now handled and generates a proper error in the latest dev release) and also for the changes not to get saved. The other problem I found is that I'm trying to save a user where only a single location is allowed (as opposed to allowing multiple locations). Currently, the code wants to save things at:

$object->locations[n][field_name]

...where n is the index of the location marked "primary". However, in my case, the existing location coming into _sf_contrib_import_location is stored in:

$object->location

...which I think is another trouble spot.

I'm happy to work on this, but could use some direction from the maintainers. A few questions I have:

1. It seems like the the import handlers should be returning an array of changed fields. How far does this go? Should we be returning the entire location object in this case, or only the fields within the location object that have changed? It seems like it has to be the former, but wanted to be sure.

2. The way the location field handlers are written, they can also affect the object being passed in (user in my case). Are these changes "thrown out" during save in favor of what's in the $changes array?

3. Regarding the $object->location vs. $object->locations thing, my approach so far has been to try and set both on the admittedly wild assumption that save would use what it needed (haven't dug into that code yet). Better thoughts?

4. Are there broader thoughts on what really needs to be happening with locations, or is it on the right track?

Thanks! Hope I'm able to help out.

Personally I always use location cck fields, so I can't really speak to location_node and location_user, so those are the fields for which support is currently the most developed. I would look at how those handlers are implemented to get an idea of how to move the others along.

Thanks for that, Aaron. I'm experimenting with that now -- I assume you mean that you use the content_profile module and add a location to the Profile content type (or types)? I've got it set up that way now (and to require the Profile during registration), and it does seem to be working better than using location on the standard user profile.

One complication, though: email address. When a user registers, they provide their email as part of the built-in Drupal user, right (and don't really want to duplicate that in my Profile content type, yes?)? I set up a map for Profile Node -> SF Lead, and I'm able to get the email address into SF by mapping "Author's Email" on the Profile node (evidently, that gets populated with the email address of the user that "owns" the profile) to SF's email field. Works fine going into SF, but when I try to import SF data into the Drupal node, the user's email address doesn't get updated. Is that a bug, or am I going about this the wrong way?

Thanks again for your help!

One other item I've run into here. Location module seems to want "codes" (abbreviations) for both country and state, and in my case at least, it's not always happy with what it's getting back from SF when I try to import (and I end up with empty values for those fields). I've got some code that will do its best to work out what the codes should be regardless of whether I'm handed abbreviations, full names, wrong case, etc. but I'm not sure where to put it exactly. At the moment, I've got it in sf_contrib.module->_sf_node_import_cck_location(), which works for me. I'm happy to contribute if it makes sense, but the other complication is the field names. Currently, I'm going into this special handling based on the fact that the $sf_fieldname is set to either "Country" or "State" (and I'm not sure how universally applicable that is). Thoughts?