Lack of custom field support

Doh lol. That line shouldnt even be there. It's not meant for public use, it's just something we want our clients to do internally so that I can explain to them the account types. So that line should be changed yea. I used this module for my own purposes and simply contributed it back so that others in the same boat could use it. The developer of this module is currently working on implementing it. I'm sure he'll see that and get it changed before he puts it in. BTW, that error msg can be thrown by multiple causes, not just the level of your account. It should actually say something to the effect of:

"Check login info and/or the services this account is able to use (Enterprise, Unlimited, etc). Contact Salesforce to find out why you cannot access this API."

The wording is up to the module dev.

At the time I was unsure what exceptions would cause this error. But over time I've found that its only for login errors and invalid permissions to use the API.

What is the status of this? I am working on yet another client that has salesforce integration and I dont see this in the dev version yet. Was there a roadblock somewhere? I am getting ready to install again and it kinda sucks that I have to edit the module again since it's not rolled into at least a dev version yet :/

Hmmm I just DL'd the .zip file I first attached to this issue and I did find 1 bug in it. I dont ever remember putting this in it as I never use shorthand if statements because they are so cryptic. Maybe I didnt see this bug previously, but I know I dont write shorthand if statements. So this is either left over from something I copy/pasted somewhere or was introduced by someone else. I HATE shorthand. Its to unreadable. I must have missed this bug somehow. Probably wasnt using a ~username based installation at the time, I dont really remember.

     //Get the path to the Toolkit, set in the options on install.
  $bpath = (base_path() != "/") ? base_path() : NULL;
  $toolkit_path = variable_get('salesforcewebform_toolkit_path', $bpath . drupal_get_path('module', 'salesforcewebform') . "/includes"); 
 

This will result in "File not found" errors for sites that use "/~username" type installations (such as a dev site).

The fix is to do this:

   $toolkit_path = trim(variable_get('salesforcewebform_toolkit_path', ''), base_path()); 

This will fix file not found errors on ~username based installations.

I found another bug that may or may not be related to the patch I included. I didnt remember this part but the webform field key has to match the salesforce field key in order for the dropdown salesforce field map selection to stick. If it doesnt match, the dropdown reverts back to Select a field. I consider this a bug. It should not do this. I am going to look into why its doing this as it defeats the purpose of making things easy. The intended feature of this drop down was so that you wouldnt need to check the salesforce page at all when dealing with the fields in webform.

Another bug I also noticed is that the WebformSID field is not autocreated if it's missing. I had intended to do this as well but it seems that part didnt make it into my zipfile. I'll have to figure out how I had done that part as well.

I have determined that the bugs I found regarding the dropdown not saving unless the keys match is because I forgot to document some changes to the salesforcewebform.module file when I first put this together. I dont know if I have time to go through and redo those changes but if I do, I'll post them here. Otherwise all I can do is say that the method for saving the field form data needs to change in order to make the UI more user friendly. Webform field's should not need to be the same as the salesforce fields (this included the webformSID field. I do remember changing how that worked). That was the whole intention of this zip, to make things user friendly and having to keep field names the same is not friendly at all. The client I wrote this for has long been completed and is now off doing their own thing and their source is no longer available on my dev servers. I guess thats a lesson in not deleting completed work lol.

Coolio. I'll try the dev version instead so we can work out patches to that :D TY

Ok, so I had mentioned previously that if the field NAME (not the label) in the webform did not match the Salesforce fieldname EXACTLY, then it would simply not save. This can be reproduced by simply creating a new field, naming it something like ertwerwrtyrty and then selecting a salesforce field to map it to and clickin save. Then go back to edit that same field and you'll notice that it does not save the value you set for the salesforce field. Here is why it does that:

On line 95 in salesforcewebform.module it has this line:

'#default_value' =>empty($form['#parameters'][3]['form_key']) ? '' : $form['#parameters'][3]['form_key'],

Now, array element$form['#parameters'][3]['form_key'] array is nothing more than the "Drupal Machine name" or the "webform field name" of the field that you were editing. So, no matter what you change the salesforce fieldname to, it's always going to have a value of whatever your drupal webform fieldname is.

To fix this is very very simple. I hadnt done this in the patch but I do remember doing this AFTER I created the patch but I guess I didnt post it. Here is what I did: I installed Queryable Variables which is a quickie method to get a fancy storage engine. I dont suggest using this as it would add a requirement to this module, but you can if you like, its pretty slick. Instead, I recommend creating a simple table with a few fields in it that will store the WF -> SF field mappings. Maybe something like:
id
nid
fieldname
sf_fieldname

These are the same fields that QV's uses. ID isnt really used for anything but I always create a table that has an ID field anyways for sorting and what not. All QV's have an ID as well.

So, once QV's is installed, add the following code on line 87

//////////////  BEGIN ADDITION
        $fieldname = $form['form_key']['#default_value'];
        $nid = $form['nid']['#value'];

        //Quickie hack to catch submit's,  could probably move this to a submit function but it works fine here as well.
        if ($form_state['post']['advanced']['form_key'])
        {
           queryable_variables_set($fieldname, $form_state['post']['advanced']['form_key'], 'nid', $nid);
        }
        /////////////   END ADDITION

Then on line 104 comment out the default_value entry and replace it like this:

            ////////// BEGIN MODIFICATION
            '#default_value' => queryable_variables_get($fieldname, 'nid', $nid),
            //'#default_value' => empty($form['#parameters'][3]['form_key']) ? '' : $form['#parameters'][3]['form_key'],
            ////////// END MODIFICATION

Now that we have the mappings stored and working properly on the forms, we need the same mappings set to salesforce as well. To do this we simply hack up the process function a little by re-arranging the array keys and values right before they are sent to salesforce.

On line 273 in the salesforcewebform_process() function right after the $form_values = $form_state['values']; line put the following:

   //Convert Webform fields into their SF Field counterparts.  Determined by using qv's.
   $nid = $form['#node']->nid;

   if ($form_values['submitted_tree'])
   {
      foreach ($form_values['submitted_tree'] AS $fieldname => $field_value)
      {
         if ($fieldname)
         {
            $sf_fieldname = queryable_variables_get($fieldname, 'nid', $nid);
            if ($sf_fieldname != $fieldname)  //We check to make sure the fields are not the same because if they are, it would simply get unset at the end here and we dont want that
            {
               $renumerate = TRUE;
               $form_values['submitted_tree'][$sf_fieldname] = $field_value;
               unset($form_values['submitted_tree'][$fieldname]);
            }
         }
      }
   }

   //The salesforce fields were added to the array and thus the numeric keys are now incorrect.  So we have to re-initialize the values array
   if ($renumerate)
   {
      unset($form_values['submitted']);
      $key = 1;
      foreach ($form_values['submitted_tree'] AS $fieldname => $value)
      {
         $form_values['submitted'][$key++] = $value;
      }
   }

And thats it. Then the salesforce mappings can be mapped to the drupal webform field no matter what the field name is called. I recommend using your own storage method, maybe create a new save_sf_mapping($nid, $fieldname, $sf_fieldname) get_sf_mapping($nid, $fieldname) function or something like that to make it nice and tidy. Or you can use QV's whichever you prefer, they both will work just fine. The code here shows how to use QV's because I already had it installed and it allows me to store things without having a gazzillion extra tables in my db. It's used just like drupal's variable_get/set/del functions except that it doesnt load everything into memory like the variables table and thus doesnt affect system performance when the table gets extremely large and it is far more flexible in general.

The issue is completely explained above as to how this is the case. So everyone has this issue. Its not even possible that it could work for you unless you have somehow fixed the bug inadvertantly with your implementation. If you look on line 95 in salesforcewebform.module, you'll see that the default value is filled in with the wrong value. Its filled in with the WEBFORM field name rather than the selected field value. It will only work if BOTH values are identical. My guess is that your webform field AND salesforce field names are identical which would cause you to NOT see the problem.

I also found a slight bug regarding Case and field names. Salesforce seems to send the fieldnames in different cases which causes PHP to have TWO versions of the same field in the salesforce object. To fix this, simply lowercase ALL the fields in the object and then you will end up with the correct object that needs to be sent to salesforce. The below code does this. Simply search for $success = in the module and put the following code directly above it.

  //Make sure each field is listed only once!  PHP is case sensitive, SF is not.  So its possible that a field could have been listed twice.  -Ryan
  if ($sObjects)
  {
      foreach ($sObjects[0]->fields AS $fieldname => $value)
      {
            $new_fieldname = strtolower($fieldname);
            unset($sObjects[0]->fields[$fieldname]);
            $sObjects[0]->fields[$new_fieldname] = $value;
      }
  }

  $success = _salesforcewebform_upsert_accounts($client, $sObjects, $file_updated, $file_created, $file_failed);