| Project: | Salesforce Suite |
| Version: | 7.x-2.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | D7 porting |
Issue Summary
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....
Comments
#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.
#7
The same can be accomplished with CCK Computed Field.
What advantage does this patch offer?
#8
CCK fields can only be added to nodes.
In particular, they cannot be added to ubercart orders, or other custom tables.
- Bibek
#9
OK, I see where you are coming from.
It makes sense to have such an option for non-node based mappings.
I've re-rolled the above patches into a single patch against the latest dev, and applied fixes for sf_node and sf_user as well as some other changes.
There are couple of changes in this patch that will likely be rolled into dev before this patch is RTBC, so the final version will be a little different.
Anyway, please reinstall and apply the new patch to the latest dev release and lemme know how it goes.
I have not tested against uc_salesforce, but that might be worthwhile as well.
#10
as mentioned above, some of the above patch has already been applied to dev.
Please use this one:
#11
The patch in #10 does not apply cleanly to the 2010-Mar-17 salesforce-dev. Attached is a patch that applies cleanly.
(No code was changed in this patch; it just fixes a rejection of the last modified hunk from salesforce_api.module, because the context code before it changed a little).
Note that I have not tested this yet, aside from assuring that the resulting code will load and run. In particular, I'm having trouble establishing a connection with the latest code (with or without this patch). I'm looking into it.
#12
If the code needs to evaluate the active salesforce object (as opposed to its object definition), then the new patch (in #10 and #11) does not seem to work.
This can be fixed by using pieces out of the old patch (as the new patch is much more elegant), but it does not work as-is.
Also, if there are parse errors in the evaluated code, then a "Parse Error" message is printed directly to the output stream, with no indication of where it came from - what field, code, etc. This cannot be caught directly, but it could probably (??) be caught indirectly using an output buffer.
It's would also, I think, be possible to do this as a separate module (perhaps distributed with salesforce), rather than requiring it to be a patch against the main API. The import / export handlers should allow enough functionality for that.
Oh, and it broke uc_salesforce - but that's to be expected, given the nature of its changes. That piece was easy to fix.
#13
The Salesforce + FormAssembly integration has something very similar to this.
I'm just going to track this issue for now, but will probably try testing later. I also would like this for Ubercart integration purposes.
#14
updated patch from #11, which was no longer applying cleanly for me.
#15
ignore #14 - this one will work
#16
sorry, still not quite ready for prime time.
#17
The latest patch is treating $map as an array instead of an object in salesforce_api.admin.inc on lines 554-559 & 628, and in salesforce_api.module on lines 774-784.
Also, the field maxlength on line 577 in salesforce_api.admin.inc is only set to 128, which is rather limiting for a php value.
#18
Here's a re-roll of the patch with the issues @mearnest mentioned fixed. However, it still doesn't seem to be working for me, at least with uc_salesforce. I will try again, hopefully with a simpler test case.
Could someone else review, preferably with a very simple SF & Drupal setup?
#19
Oops...I missed 2 instances of $map['fields']. This one should have that problem fixed, at least.
However, the new fixed value field still isn't exporting for me in my current test case. Am going to do more debugging.
#20
Figured out why the patch wasn't working...needs to have salesforce_api.admin.js, or else the $map->fields[$sf_fieldname]['type'] variable was set to an empty string rather than fixed or php. When @aaronbauman re-rolled the patch, that didn't get cvs added, and thus wasn't in the diff.
Also, the case statement in salesforce_api_fieldmap_export_create() could probably be rewritten with case 'fixed' directly above default so that it would use the fixed value option even if, for whatever reason, the type is not set.
aaron can you re-roll the patch with the file added? The file is attached below.
#21
Just tested the patch again, after adding the file from #20 to salesforce/salesforce_api/misc as salesforce_api.admin.js.
The patch works now, with no known issues yet, but it means that JS is required on the fieldmapping page, since the JS is what hides/shows the "special" options for fieldmapping - fixed value and PHP.
Aaron, can you re-roll adding the file from #20 using cvs add? I don't know how to make a diff in a situation like this.
#22
Just discovered that if you have prematching set on a field in an object that has a fixed value in it, the patch in #20 will generate the following error:
array_flip() [function.array-flip]: Can only flip STRING and INTEGER values! in salesforce/sf_prematch/sf_prematch.main.inc on line 29
In order for the patch to work with prematching, the following has to be added to sf_prematch_export in sf_prematch.main.inc:
<?php$values = array();
$select_clause = "SELECT id";
// unset the fixed value fields since they cannot have key/value flipped
foreach($map->fields as $fieldname => $field) {
if(is_array($map->fields[$fieldname])) { unset($map->fields[$fieldname]); }
}
$drupal_to_salesforce_fieldmap = array_flip($map->fields);
?>
I may get a chance to re-roll using cvs fakeadd in the next week or two, but if anyone wants to beat me to it, that would be great.
#23
OK #19 & 20 are into dev
Thanks to everyone who worked on this
http://drupal.org/cvs?commit=458970
#24
For some reason, when I tried export of a RecordTypeID recently using the fixed values feature, it was not actually getting exported.
I think that this is because the $value is getting checked in the part of the for loop following
// Evaluate field-type-specific syntax rules., and it hasn't been unset from the previous iteration through. Thus, if $value was set to be a text string, such as the Name for an Account, and now it is checking for a 'reference' or 'id', it will pass a text string to is_sfid, which will fail validation, and thus the value will not be set.I think the special field code should actually be the following to resolve this issue (note the assignment of $value):
<?php// See if it's a special field
if (is_array($map->fields[$sf_fieldname])) {
switch ($map->fields[$sf_fieldname]['type']) {
case 'fixed':
if (isset($map->fields[$sf_fieldname]['value'])) {
$object->$sf_fieldname = $value = htmlentities($map->fields[$sf_fieldname]['value']);
}
break;
case 'php':
if(isset($map->fields[$sf_fieldname]['value'])) {
$object->$sf_fieldname = $value = htmlentities(eval($map->fields[$sf_fieldname]['value']));
}
break;
}
}
?>
#25
i inadvertantly stumbled on this same issue, and committed a fix to dev just yesterday.
Adding
<?php
$value = '';
?>
to the beginning of the for loop fixed it for me.
Please check out the new dev and let me know if you still have the issue
#26
Won't have time to test for a few weeks, but I'll let you know.
#27
I'm just going to set this back to fixed to avoid confusion. I'll reopen if I hit the issue again.
#28
#29
Will be in 7.x-2.x-dev.
#30
#31
Automatically closed -- issue fixed for 2 weeks with no activity.