As discussed in the following thread from the Salesforce API module http://drupal.org/node/357712 the dependency on SF_Node module needs to be removed in favor of directly mapping the Salesforce object to the webform submission.

CommentFileSizeAuthor
#14 445616.patch756 bytesBevan
#7 sf_webform_445616.patch17.04 KBstella

Comments

andybrace’s picture

andybrace commented
Category: task » feature
Bevan’s picture

Bevan commented

Have you (or anyone else) started work on this? I'm starting today.

andybrace’s picture

andybrace commented

ill be working on this during the week, will hopefully have something to test out by the beginning of next week.

Bevan’s picture

Bevan commented

Great! I was hoping to get to it this week too, but that hasn't worked out.

Bevan’s picture

Bevan commented

Any progress here?

andybrace’s picture

andybrace commented

No update on this issue yet. Im back focusing my attentions on this project at the moment so should be able to submit an update soon.

stella’s picture

stella commented
Status: Active » Needs review
StatusFileSize
new sf_webform_445616.patch17.04 KB

First attempt, seems to work with my developer edition account when creating leads. However I'm not too sure why the "user login status" feature is needed. I've left it in though, but untested.

andybrace’s picture

andybrace commented

Thanks. Ill test this out and let you know how this works for me.

The "user login status" feature was motivated by the need to allow different Salesforce workflows depending on whether the user already has a Drupal account (with a potentially matching Salesforce record) or not. Taking the example of a contact page webform: if the user is anonymous then the submission is exported to an SF 'Lead' whereas authenticated user submission can be exported to a 'Task' that is related to the Salesforce User object.

Bevan’s picture

Bevan commented

The "user login status" is a nice feature, but is something that should be in salesforce_api. It would be good to remove it from sf_webform and get it in salesforce_api.

I noticed that with this patch it's possible to have two mappings between the same types. I'm not sure if this was possible before or not, though I think salesforce_api should be checking for this case and disabling or discouraging it (not sf_webform).

There are a lot of code style issues that the patch fixes, but many more left unfixed. These can and should be addressed in a different patch/issue though.

The module (possibly not this patch) needs to implement a local tasks on the webform submission view/edit page (node/%node/submission/%webform_submission) to see salesforce syncronisation status. Kind of like sf_node does on node/%node

Also, I couldn't get it to actually synchronize the webform submission to Salesforce.

OpenBook, Did you get to review/test this? Great to meet you at DrupalCon, btw!

andybrace’s picture

andybrace commented

I tested this patch briefly and there were a couple of small issues but im going to be spending time today and this weekend on getting it into the latest dev release. Ill leave the user status functionality in for now but like you said it would be good to get this into the Salesforce API to reuse for other exports, ill try to get this rolled in to a patch when I get a chance.

Bevan, likewise good to meet you at DrupalCon, would have been to chat to you more so sorry I left it to the last day to say hi but it was a busy week!

Bevan’s picture

Bevan commented
Status: Needs review » Reviewed & tested by the community

Ignore my comment in #9 about not getting it to sync to Salesforce – that was another issue. I'd say this patch is RTBC. Even if it's not perfect and there is still work to do to properly separate from sf_node, it's a big and important step in the right direction.

andybrace’s picture

andybrace commented

Patch is tested and working ok. I made a minor change so that the "Automatically Populate Salesforce?" value is saved correctly and also so that the user login status option is available. Ive run the module through the coder review module as well so this should solve the issues described in #572412: Not all wachdog calls are properly coded. Ive just committed the changes so they will be available soon.

andybrace’s picture

andybrace commented
Status: Reviewed & tested by the community » Fixed
Bevan’s picture

Bevan commented
Status: Fixed » Reviewed & tested by the community
StatusFileSize
new 445616.patch756 bytes

You missed changes to sf_webforn.info.

andybrace’s picture

andybrace commented

Darn. Committed: http://drupal.org/cvs?commit=263688

Bevan’s picture

Bevan commented
Status: Reviewed & tested by the community » Fixed

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.