Im testing out the dev D6 version and have found that the webform fields don't appear when mapping fields to the Salesforce objects. Are there already plans to integrate the webform module (if so what options are being considered? integration / reliance upon the http://drupal.org/project/salesforcewebform project ?) I'm looking to integrate Salesforce on a D6 site and can help out with issue or others wherever needed.

Comments

mlncn’s picture

Assigned: Unassigned » mlncn

The author of salesforcewebform (Bryan O'Shea), the present maintainer of this Salesforce module (JoshK), and myself (I have a fork of the D5 Salesforce that provided for arbitrary mapping of fields with Webform as the main implementation, that very sadly for me never got committed back in) all at one point committed in principle to merging the projects.

It is D6 upgrade time for our clients (approximate due date: yesterday) so I'm going to take a crack at it. If I choose to upgrade our version of the Salesforce module rather than make one or both of these two solutions work, please bury me in the duplicated modules hall of shame.

@Openbook, what are your feature/specs/requirements?

@JoshK, is the code in CVS the most current? Likely patch coming!

benjamin, Agaric Design Collective

andybrace’s picture

StatusFileSize
new85.55 KB

Hi Benjamin

The aim for our project is to integrate Salesforce and Drupal so that Salesforce acts as the main user management system whilst Drupal is used as a front end to allow users to update their preferences. Specifically the following are critical:

Sync of users between Salesforce / Drupal (as Salesforce contacts) - so users can sign up using Drupal and appear as Salesforce contacts, and also so that contacts can be added in Salesforce (or converted from Leads) and would receive a Drupal account.

Export webform submissions to Saleforce as leads - essentially to replace the contact form so that when the site is contacted a Salesforce lead is created. However it would be good to make this as generic as possible so that other Salesforce objects can be created by webforms.

Support for Salesforce custom fields - custom fields added to Salesforce need to be accessible to Drupal as well.

Import / export should be available to run via cron or manually (at the time of the form post)

Because of the time constraints involved I have started trying to get these functions working based on the 6.x.2-dev version of the Salesforce module (sorry I know another branch is a bit counter productive) but it is my first attempt at integrating Drupal with Salesforce and therefore a bit of a proof of concept rather than finished code, so would need a bit of review / tidying up. I have just started working on this project again after a break so let me know if I can help out with any of the work. Ive attached my code.

joshk’s picture

Hey guys!

Big update just went in for DRUPAL-6--2: http://groups.drupal.org/node/19498

Please offer patches here and I will work on getting them integrated. Basically I think we should start a sf_webform.module, and implement the API just like the node and user modules do.

This would principally mean:

  1. Implement function sf_webform_fieldmap_objects(), returning a set of fields for every individual webform. This won't scale very well if you have 100s of forms, but I don't think that's very common. Look to how sf_node returns a set of fields for each node_get_types() for an example.
  2. Hooking into the webform_submit handler and passing mapped fields to salesforce. This should be easy: the old modules already ahve the hook, and the new API makes sending the data over pretty much a breeze

The only really problematic thing I can think of is that if someone sets up a fieldmap within a webform, and then changes or removes some key elements that were part of the map. This is a general issue with CCK also -- yes, Matilda, you can screw your site up if you try -- so I don't think it's a "must have" at this point. However, eventually some kind of error checking would be nice, if only to warn admins if they're about to invalidate a salesforce fieldmapping.

mlncn’s picture

Finally back at this now.

@openbook - anything new you want to check in?

andybrace’s picture

StatusFileSize
new8.31 KB

Hi guys

As part of the work I was doing I created a salesforce to webform module, it was my first attempt at working with the salesforce api so I dont know how useful or complete it is but fundamentally it uses the same process as described by joshk above:

1) when creating a fieldmap for a webform node the form fields are loaded into the hook_fieldmap_objects()
2) Ive hooked into the webform submit handler so that the submission data can be passed to sf_webform_export function and mapped for export.

The module also features:

1) manual / cron export
2) ability to select anon / auth / both

As Josh said changing webform fields will mess up the fieldmap so this is an issue I will need to look at. The code is early alpha at best so Im sure its going to need some testing / modifications before it could be used on a production site, I hope it can be used as a base for future development though and save someone else dupping the work.

JoshK - let me know if you would like to incorporate this into your Salesforce module or whether you think it should exists as its own project so that issues can be handled separately (in which case I could look at setting up a separate drupal project).

mlncn’s picture

Status: Active » Reviewed & tested by the community

openbook -- I am using your tar and it is working great so far. Congratulations!

With CVS access, I can help maintain this if it is added to Salesforce or as a separate module.

benjamin, Agaric Design Collective

Bevan’s picture

Status: Reviewed & tested by the community » Needs review

I really think this should be a separate module. The convention for contrib projects that provide hookable APIs, like salesforce_api, views, cck etc seems to be;

  • maintain support for integration with Drupal core modules and objects (nodes & users in the case of SF) in separate modules but in the the same project/package that provides the API
  • allow other contrib modules/packages to provide integration with other contrib modules/packages. This can be as part of the module it integrates, or indepenent of both dependencies.

I think this is a good model.

I'm working on something similar to what is discussed in this thread for a client at CivicActions, and have started a project that I'm calling ppd2sfl; Paypal Donator to Salesforce Lead for now.

It will initially support Newsletter-subscriber-to-SF-Lead, then also support Paypal Donator to SF Lead.

I'm not yet decided on whether to use webform or not, since I really don't like the Webform module. however this module seems like it might get us halfway there, so I may end up committing it to ppd2sfl and continuing it's development from there. I'm going to review this module now.

Please contact me if you are interested in collaborating financially or with developer time.

andybrace’s picture

@Bevan

Id come to the same conclusion and have been preparing the code to be committed to the Drupal CVS very soon.

The current Salesforce to Webform module (http://drupal.org/project/salesforcewebform) currently only supports the creation of Salesforce leads whereas the code I posted can be used to create any Salesforce object (I also have a patch to commit for the Salesforce API which removes the restrictions on the objects you can created) so im going to setup a new Drupal project for this code, will post a link here once this is done.

Bevan’s picture

OpenBook; Great! Let us know. I'm playing with your module now. Is the version you uploaded in #5 the latest version?

Bevan’s picture

Oh, and where is that patch? I couldn't see it in the issue queue. I think I might need it, and am happy to review it for you.

Also; I've requested commit access to salesforce module so I can clear up these bugs and the issue queue.

Bevan’s picture

Status: Needs review » Needs work
StatusFileSize
new91.76 KB
new73.43 KB

I think the way you have implemented this module is less than ideal.

It has a dependency on sf_node module. Aside from the fact that the dependency is not declared in sf_webform.info, it need not be dependendent on sf_node, and, further, this dependecy generates significant extra complexity in the module than is necessary. It also makes it's usage and the UI daunting, confusing, and error-prone.

I would like to rework it so that it;

  • Is not dependent on sf_node.
  • Exposes it's own object type, E.g. "!node_title webform", instead of tacking on to sf_node's "Webform node" object. See the attached annotated screenshot.
  • Principally allows mapping Webform.module's components to SF fields, instead of $node fields, then webform fields. See the attached annotated screenshot.
  • Does not need to use sf_webform_fieldmap_objects_alter().
  • Does not use arg() to determine context.
  • Simplifies the rest of the module as a result of the above, reducing (elminating?) the amount of FAPI and theme code.

I'm not sure if it will be easier to start fresh or continue with this module – or a combination of both. However I would first like to get the latest version of this module, if I don't already have it. Can you please confirm?

andybrace’s picture

Ive continued working on the code since I uploaded the snapshot so although this isnt the latest version the issues you pointed would still apply. In the latest version Ive tidied up the code and added a new hook to allow for additional actions to be performed pre and post export of the submission.

I can see the benefits of making the changes you mentioned (although im not sure how much the UI can be simplified as it relies mostly on the Salesforce API module for this, and there is only one theme function) as I am going to be continuing to work on the code as part of an ongoing project Id like to carry on with the development taking on board your comments, looking to get a new project page setup and the updates made as soon as possible and would be grateful for any further help / feedback.

Bevan’s picture

Let's collaborate! :)

I was planning to work on reworking the module today. Could you send me your latest code? I can help you get into CVS faster if you're still waiting for a CVS account, and can contribute the changes as a patch if you like.

Ping me through my contact form if you like; http://drupal.org/user/49989/contact

mlncn’s picture

When you two connect, if the collaboration goes offline, please be sure to loop me.

benjamin, Agaric Design Collective

joshk’s picture

Hey guys; I'm sorry for not being more up to date on this issue.

I think this is a good start, but I'm inclined to agree with Bevan about the dependency on sf_node. Even though webforms are nodes, the drupal-side thing you're trying to sync with SF is not the node itself, but the webform submission.

What we'll need is the ability to create separate mappings for each webform-submission-type. That is, each webform node in the system would have its own mapping to salesforce.

joshk’s picture

Also @bevan feel free to merge http://drupal.org/project/ppd2sfl into this project if you like. I think the salesforce download should come with a lot of helpful sub-modules (ala messaging/notifications).

andybrace’s picture

Hi Guys

Ive setup a project page for the SF Webform module (http://drupal.org/project/sf_webform) and have posted an issue which is to get the dependency on SF Node replaced so ill be working on getting the code updated with Bevan as my first priority.

Bevan’s picture

Project: Salesforce Suite » Salesforce Webform Integration
Version: 6.x-2.x-dev » 6.x-1.x-dev

Perhaps we should just mark this as 'fixed' or 'won't fix' and continue discussion at #445616: Remove dependency on salesforce node module?

Bevan’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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