Compatibility with latest dev, code cleanup, some bug fixes

So, looking at the CVS messages, this is newer than any of the commits on this module, so I presume that it is necessary in order to get this module to work with the newer dev of Salesforce API.

However, the module will never enable currently b/c of the new line 7 of uc_sf_order.info.

It should be:

dependencies[] = content

since CCK is the content.module.

I could attach an interdiff, but probably better if you could just re-roll the patch :)

More feedback shortly, after I have a chance to see if I can get this working.

The uc_sf_order_default_uc_order_opportunity_field_map & uc_sf_order_default_opportunity_contact_role_field_map default fieldmaps are not showing up for me. I have all the Salesforce API modules enabled. Where are they supposed to appear?

The patched version of the module is causing the following error message to show up on cart/checkout/complete whenever an Ubercart order is submitted: "The website encountered an unexpected error. Please try again later."

Nothing else shows up on the page - it is as if I have lost database connection. I have Drupal set to show errors on screen, since this is a test site, but the error is not showing.

Subsequently to this, when I reload the page, I see "SoapFault: INVALID_TYPE: Must send a concrete entity type. in SoapClient->__call() (line 399 of /sites/all/modules/salesforce/salesforce_api/toolkit/soapclient/SforceBaseClient.php)".

Note that I am running Ubercart 2.4. Possibly this patch is no longer compatible with the latest version of Ubercart?

The errors I mentioned in #3 were caused apparently by either: a) my field mapping on Opportunity Contact Role, or b) setting Ubercart order contact role to sync to Salesforce OCR in general. (Note: I was not using the OCR node, since it seemed to be causing issues. I will try it again momentarily.)

Below is my field mapping on OCR:

$salesforce_field_map = new stdClass;
$salesforce_field_map->disabled = FALSE; /* Edit this to true to make a default salesforce_field_map disabled initially */
$salesforce_field_map->api_version = 1;
$salesforce_field_map->name = '159efa613ad906829b84c499628eaa69';
$salesforce_field_map->automatic = 7;
$salesforce_field_map->drupal = 'uc_order_contact_role';
$salesforce_field_map->salesforce = 'OpportunityContactRole';
$salesforce_field_map->description = '';
$salesforce_field_map->fields = array(
  'OpportunityId' => 'uc_sf_order_order_sfid',
  'ContactId' => 'uc_sf_order_user_sfid',
);

I can confirm now that the same issue happens also when I map based on the node. Here's the export of that:

$salesforce_field_map = new stdClass;
$salesforce_field_map->disabled = FALSE; /* Edit this to true to make a default salesforce_field_map disabled initially */
$salesforce_field_map->api_version = 1;
$salesforce_field_map->name = 'bc0180f5968cb70b816c4f1eaddbf056';
$salesforce_field_map->automatic = 7;
$salesforce_field_map->drupal = 'node_opportunity_contact_role';
$salesforce_field_map->salesforce = 'OpportunityContactRole';
$salesforce_field_map->description = 'Opportunity Contact Role mapping';
$salesforce_field_map->fields = array(
  'OpportunityId' => 'uc_sf_order_order_sfid',
  'ContactId' => 'uc_sf_order_user_sfid',
);

I'm wondering whether the ContactId is going missing because uc_sf_order_user_sfid is not getting data in it (likewise, with OpportunityId, most likely). The OCR nodes are getting created, however. (Although they have no titles, which should probably be fixed.)

By the way, I'm bumping this to "major", since uf_sf_order.module is not usable with the latest dev of the Salesforce API module until it is patched, and this patch needs work.

Currently, I have created a sfautogen_organization_name field that is added to $order in _uc_sf_order_do_export. It's a "magic number" right now (i.e., a hard-coded Account ID), but I think I could turn this into a lookup of the Account linked to a Contact based on Contact ID. That way, I would be able to see Donations listed properly on the Account record, even though OCR is not working for me.

I have to figure out, though, why the export on admin/store/orders/%/salesforce is not exporting that field, though, when it is exporting the others. (Possibly I need the submit handler on that form to add it back into the $order object, since it's not actually stored in one of the Ubercart order tables.)

I figured out that it was just my $account_sfid that wasn't getting populated. This was happening since I was using a Profile node (machine name "profile") for my mapping to Contact, rather than using the profile.module integration provided by sf_user.module.

The following code got that field populated. However, there is still an error happening somewhere in the OCR generation process which is causing "The website encountered an error" to show. I'll look into that further tomorrow.

function _uc_sf_order_export_values($source, $field) {
  $ret_val = NULL;
  if ($field == 'uc_sf_order_order_sfid') {
    $order_id = $source->field_order_id[0]['value'];
    $order_sf_info = salesforce_api_id_load('uc_order', $order_id);
    $order_sfid = $order_sf_info->sfid;
    $ret_val = $order_sfid;
  }
  elseif ($field == 'uc_sf_order_user_sfid') {
    $account_id = $source->uid;
		
    // following code is required if you're using sf_user
    // TODO: have either a variable_set, or a lookup of mappings to make this conditional
    /* $account_sf_info = salesforce_api_id_load('user', $account_id);
    $account_sfid = $account_sf_info->sfid;
    $ret_val = $account_sfid; */
		
    // following code is for sf_node + content profile
    $profile = content_profile_load('profile', $account_id);  // TODO: need to lookup name of content type
    $account_sfid = $profile->salesforce->sfid;
    $ret_val = $account_sfid;
  }

  return $ret_val;
}

I was able to get the OCR mapping working with this patch after I switched to using sf_user instead of sf_node + content_profile.

Therefore, this patch is ready to go except for the issue of the .info file saying "cck" instead of "content". I can re-roll with that, and reset this to "needs review".

Here's a re-roll of the patch that fixes the issue mentioned in #1, and also adds the fieldmapping urls that were missing previously from the admin interface.

I think you'll have to apply it with patch -p1 if you are inside the uc_salesforce directory. Otherwise, apply it from sites/all/modules.

It should be good to go, except for the potential problems with applying it. I might try within the next week to re-roll using CVS fakeadd to add the files, then CVS diff if it hasn't been reviewed by that point. Once I have a clean re-roll using CVS diff, I will mark it RTBC if no other feedback has come in from Bibek, Aaron, or other reviewers, since this is very similar to Aaron's original patch.

If I get commit access to the module, I will also add in #953628: User fieldmap dropdown added to Salesforce API configuration form has no corresponding submit handler logic, which I have working on my copy of the module.

I will release the current dev (prior to the patch) as alpha1, and then release the version that is compatible with the current Salesforce API module as alpha2.

Fixed in alpha2. alpha1 has the code prior to this commit.