sf_node and sf_user need import/export functions for more cck field types.

First: check out sf_node and sf_user in the salesforce package (you've probably done this already).
sf_node allows automatic D->SF updating.
sf_user at this time does not implement an analogous feature, but could be made to do so without much trouble.

To keep, e.g. Users and Contacts in synch from D->SF, you should be extending sf_user

As w/ sf_node, imho it's essential that the auto-synch be an optional feature,
since some sites will not desire such functionality, but may prefer to synch via cron or manually every so often.

/a

ps. Forgot to mention that you'll need to create a fieldmap to tell Drupal and SalesForce which fields are related to one another...

thanks, got it working with content_profile!

It took me 3 hours though, as I've overlooked your patch for sf_node.module :/
I ultimately came up with exactly the same patch, so I can confirm both the problem and the solution.

I'm still not happy w/ this solution.
I just tried your solution, al.ex, solution, and there's still work to be done.

First off, Location module doesn't play nice w/ salesforce, so it's currently impossible to synch locations.
Secondly, the user's email address doesn't show up on the content_profile node_form. Therefore Email doesn't get synched. In fact, the SalesForce account email is used instead.

These are not big issues...
I've got the locations bit sussed for export already, and I'll post a patch once I've got location import and the email issue figured out too.

I'm updating the title of this issue to reflect this task more precisely.

subscribing...

Let me know if I can help at all as we are experience the same issues.

after spending some time writing some import/export functions, i can see that cck fields are quickly gonna get out of hand.

As of now, sf_node and sf_user can handle only a few standard cck fields like text and date.
Fields like location, nodereference, content_taxonomy, etc., need to define their own import/export functions and set them up in a hook_fieldmap_objects implementation.

It's not realistic to expect that modules will roll this into their releases, so sf_node and sf_user should each implement a subdirectory with any such implementations. What should it be called? modules?

Since the point of the new subdirectory is to hold field-specific code, I would suggest calling it fields, CCK_fields, field_handlers, or something along those lines.

I would also suggest a naming convention such as field_name.inc. That way the main code would have a straightforward way of finding a file for a field.

I created an initial module for Salesforce integreation with the Location module. We are using CCK Location and I have it working with Profile Locations, CCK Locations and standard location fields. So far, it only supports the first location and not a location with multiple instances but I wanted to share it and see if other people can help to improve it.

In moving toward handling multiple values, please see http://drupal.org/node/506032 which I believe implements (at least the beginning of a) framework for doing so.

I agree support for more CCK field types would be great. These should probably go in sf_node/fields/FIELD.inc as previously suggested. This issue node is too general for this though. Please create new issue nodes for each new field type or feature. E.g. #506032: CCK checkbox groups do not sync correctly

Code that integrates salesforce API module with modules other than Drupal core modules, views and CCK, should go into their own Drupal contrib projects so that they can be maintained independently.