Salesforce PFG Adapter 1.5 (Alpha release)

This is not a final release. Experimental releases should only be used for testing and development. Do not use these on production sites, and make sure you have proper backups before installing.

For additional information about this project, please visit the project page.

Available downloads

Click to enlarge

Product Package (alpha 1)

For all platforms (35.6 kB)

Product Package (alpha 2)

For all platforms (41.1 kB)

Product Package (alpha 3)

For all platforms (42.0 kB)

Release Notes

NOTE: If you are upgrading from version prior to 1.5alpha1, you must reinstall the product to trigger the migration of existing Salesforce Adapters to the new behind the scenes handling of form field to Salesforce.com sObject field mappings.  Otherwise, you'll lose your existing mappings and will need to reconfigure!!

Release includes the following features: 

Configuring Parent Adapters

Now, if you configure a form that contains multiple "Salesforce Adapters" and your version of Salesforce PFG Adapter is >= version 1.5.x, you also have the ability to relate the resulting Salesforce.com provided unique "Id" for each adapter to a field of your choosing on later executed adapters.  This is how one can create related Salesforce.com (via a lookup field, which is conceptually similar to a foreign key) records from a single form.  Take the following scenario as a visual example with two sObjects and their inherent schemas:

 -----------                -------------
 | Account |                | Contact   |
 -----------                -------------
 | Id      | -------------> | AccountId |
 | Name    |                | LastName  |
 -----------                -------------

In the above scenario, the "Account" adapter will be run before the "Contact" adapter regardless of ordering within the PloneFormGen form.  In this sense, the "Contact" adapter is *dependent upon* the result from the "Account" adapter. Upon creation of the "Account" within Salesforce.com an Id like "01r600123009QiJ", will be returned along with the API response.  This will then be saved and can be configured to be inserted into the "AccountId" field for the "Contact" record that is next created. Care is taken via validation to ensure that "circularly dependent" adapters can not be accidentally configured.

Change log

1.5a3

- Better handling of empty FormIntegerField values, which when left blank were filled
  by an empty string that was being passed along within the created object.  In the case
  of a string-like field, this was fine, but integer fields (i.e. documented as xsd:double and
  xsd:int format in the SF WSDL) were another story.  This resolves:
  http://plone.org/products/salesforcepfgadapter/issues/8
  Note: If a FormIntegerField was a required field and therefore came through as expected
  in the request, this was handled properly [andrewb, thanks greenstork for bug report]

1.5a2

- The mutator for our SFObjectType field now takes into account the fact that there

  could exist invalid field mappings and/or dependency mappings for the ultimately

  chosen sObject type, which could lead to an Invalid Field exception, should the

  mappings not be reconfigured.  This is primarily useful in the case where the user

  sets up an adapter to create one field type, but later switches to another.  This

  fixes the following issue:

  http://plone.org/products/salesforcepfgadapter/issues/7 [andrewb]

- Appropriate cleanup of renamed and/or removed adapters with the Parent Adapter

  mapping interface.  Similar approach to what exists for field mapping cleanup. [andrew]

- Better handling of empty FormDateField values, which were plagued by errors casting

  to DateTime format and if successful an invalid xsd:dateTime format.  This resolves:

  http://plone.org/products/salesforcepfgadapter/issues/6

  http://plone.org/products/salesforcepfgadapter/issues/5

  Note: If a FormDateField was a required field and therefore came through as expected

  in the request, this was handled properly [andrewb, thanks greenstork for bug report]

- Adding support for PloneFormGen's FormFileField type to be populated with a binary

  file and uploaded directly to Salesforce.com upon proper base64 encoding. There may

  be other use cases, but the Attachment type in Salesforce can be associated

  with any other type, as related by the ParentId, field and is where binary data,

  stored on the Body field, is typically associated with a record. [andrewb]

- In order to reduce the configuration burden upon the user (i.e. placing Salesforce

  Adapters in the order they will need to operate), we build and run adapters from

  the final adapter within the folder.  This adapter in turn manages the needed

  order and creates the Salesforce records appropriately.  The 1.5a1 release,

  however, does not account for disabled adapters.  I.E. those that are checked

  off in the form folder's adapter field. This is now fixed. See

  http://plone.org/products/salesforcepfgadapter/issues/3 [andrewb]

- In the same category as the following issue:

  http://plone.org/products/salesforcepfgadapter/issues/3, we need to account

  for those adapters with an "execCondition" that fails. This is now fixed. See

  http://plone.org/products/salesforcepfgadapter/issues/4 [andrewb]

1.5a1

- Adding new DataGridField FixedColumn with visibility set to false for the
  the 'fieldMap' schema field on the Salesforce Adapter, which stores the relative
  path from the parent form to the field in question.  Previously, we were 'building'
  the data structure for the soon to be created Salesforce object based on mappings
  keyed off of each field's title.  Since titles aren't necessarily unique, this
  was fragile and with the introduction of support for mapping fieldset-based fields,
  the code was getting ridiculous.  *NOTE*: If jumping to this version of
  salesforcepfgadpater from previous versions, you'll need to reinstall
  the product from the ZMI or the Add/Remove Products control panel. 
  This will trigger the migration of all existing Salesforce Adapter objects,
  to include this essential new column for the field map. [andrewb]

- Reworking overly fragile 'do we need to migrate' infrastructure for versions
  prior to 1.0rc1 which assumed that we'd be listing all known versions to the
  end of time and also that running a profiles steps wouldn't bump the installedversion
  attribute on an installed product, as it now appears to do in CMFQIT
  version 2.1.4. This should allow for a simultaneous Plone 3.1.x migration and
  Salesforce PFG Adapter upgrade. [andrewb]

- Added support for form fields within a folderish "fieldset" both from a
  mapping and creation within Salesforce.com objects perspective. [andrewb]

- Adding test/code coverage protecting against a maximum recursion depth
  exceeded error via a direct call to getSortedSFAdapters.  This is feasible
  in the case where Salesforce Adapters are configured outside the context
  of the existing Archetype validation code. [andrewb]

- Added support for "chained adapters" (that is, forms that create
  separate, but linked SF objects) including: schema extensions for adapters,
  validation against circular chains, and execution of chains in the correct order. [jbaldivieso, andrewb]