Fixed values when creating fieldmaps
| Project: | Salesforce |
| Version: | 6.x-2.x-dev |
| Component: | User interface |
| Category: | feature request |
| Priority: | normal |
| Assigned: | openbook |
| Status: | needs review |
When creating fieldmaps Ive almost always had to create hidden fields for nodes or webform submissions in order to pass static data to Salesforce (ie object ids, static text). Although this method works fine duplicating data for each node/submission is far from ideal. Also the process of adding a hidden field is outside of the fieldmap creation process, instead its done using the admin content type pages, webform config page.....etc. This complicates the setup process for site admins.
Ive created a patch that adds an additional 'Fixed value' option to each of the source select boxes on the fieldmap add/edit page. When the site admin selects the fixed value option a hidden text field next to the select box is revealed using js, this field can be used to enter a static value that is used when exporting data.
The patch alters the fieldmap definition array so that fields with a fixed value become an array with 'type' and 'value' keys. When Drupal creates the object for export if the fieldmap definition contains a field with type = 'fixed' then the static value is used.
If people think is a useful feature then the idea could be extended further to include a Salesforce ID look up for the static data.
eg
1. site admin click 'sf lookup' link next fixed value textfield
2. a popup presents a form where the user can view a list of all salesforce objects filtered by type
3. user clicks on the Salesforce object they want to use as the fixed value
4. the popup closes and the textfield is autopopulated with the ID of the selected Salesforce object.
To apply the patch use the "-p0" option (eg patch -p0 < salesforce_api_xxxxxx.patch) to avoid having to confirm filepaths.
Thoughts, feedback, bugs are welcome....

#1
#2
#3
I have not yet had a chance to apply this patch - but I'm glad to see it!
My two cents, the Salesforce ID lookup sounds like a very useful feature. I can't quite think of a use case for it at this point, yet, though.
#4
I've applied this patch to my own setup, and found it to work correctly.
This will help IMMENSELY in the uc_salesforce code. And here I was considering writing such a patch.
What's the policy on changing the "Status:" field? Is that something only the sf-api maintainers should change, or should I change it since I'm using it, and am part of the community? (leaving status as-is for now)
#5
The attached patch adds the ability to use PHP in fixed-value fields to the patches in #1. Remember to activate the permission.
It requires the patches in #1 to be in place prior to patching.
#6
Bug in the patches in #1: Makes all ".form-item"s to display:inline.
Attached patch fixes it.