Bug: sf_user allows creating many-to-many relationships between SF and Drupal objects, even as it assumes they're one-to-one

I like this approach, but i don't think it fully solves the problem.

The root of this issue is that salesforce suite assumes a one-to-one relationship between drupal and salesforce objects, even as it provides the ability to create any number of fieldmaps for any number of Drupal and SF objects. This broken-ness is mitigated by sf_user_user() and sf_node_nodeapi() falling back to using the first fieldmap (based on the arbitrary order returned by salesforce_api_salesforce_field_map_load_by()).

The patch in #2 addresses the case where the drupal object is not yet linked to a salesforce object, in that it exports one salesforce object for each applicable fieldmap. However, on subsequent updates, only the fieldmap given by $object->salesforce->name is passed to the export function.

A full solution would be something where the salesforce property of a drupal object is a 2-dimensional array -- an array of name/sfid pairs, rather than a single pair.

In other words instead of what we have now

    [salesforce] => stdClass Object
        (
            [sfid] => XXXXXXXXXXXXXXXXXX
            [name] => ce9c1624e77fca1b9419972e7be075dc
        )

the salesforce property would look like

    [salesforce] => array(
        0 => stdClass Object
                (
                    [sfid] => XXXXXXXXXXXXXXXXXX
                    [name] => ce9c1624e77fca1b9419972e7be075dc
                )
       1 => ... etc.
   )

Updating title to better reflect scope of this issue.

Right -- unless (until?) the suite fully supports many-to-many relationships, we need to give administrators better control over which fieldmap should be used in cases where there are multiple matches.

Here are some ideas, ranked vaguely from "least work/worst UX" to "most work/best UX":

1. explicitly disallow creating fieldmaps for relationships that already exist. (i.e. there can be only one fieldmap per drupal type).
2. allow duplicate relationships across fieldmaps, but only allow one fieldmap to be marked "active"
3. allow duplicate relationships across fieldmaps, but only allow one fieldmap to be marked "active" per action type (e.g. fieldmap 1 is active for inserts, fieldmap 2 is active for updates, etc.)
4. update sf suite and contribs to support many-to-many relationships

kostajh, based on your OP, it sounds like #3 (or 4) best fits your use case.

I think we should go with #3. #2 would also be acceptable.

#4 would be for 3.x, I think.

I'm getting asked by my boss for functionality something like this. He is fine with me working on the Salesforce module since everyone benefits.

I don't know how acceptable our idea is to the community, but here it is:

• Allow multiple fieldmaps for the same Drupal type & Saleforce object pairing ("one-to-one")
• Allow multiple fieldmaps for the same Drupal type but different SF objects ("one-to-many")
• If multiple matching fieldmaps are found, use each field map, not just the first one.

How does this sound? Suggestions?

The resolution to this bug, ultimately, is to fully support many-to-many relationships between Drupal and SF data.

I believe this is the point that you're getting at, and the module implementation is more than just wrapping everything in loops and updating the UI; we're also talking about changing existing data structures.

This entails lots of work rewriting and refactoring, and if you want to dive in I'm sure the community will be happy to help however we can.

Could we do option 3 from #6 in the interim before what would probably have to be a 6.x-3.x branch, or maybe, at least by some of the interest voiced by people today, be a 7.x branch?

Failing that, what about option 2?

Option 1 would make the Ubercart/Salesforce Integration module unworkable (even with the hackish way it works now), so I think that's a non-starter.

I'm wondering if allowing multiple mappings either way is workable as follows.

* Allow creation of many mapping to/from Drupal/SFDC objects.
* Add to the mapping form two checkboxes
** Drupal --> SFDC
** SFDC <-- SFDC
* Then whenever a sync is called for we iterate over the appropriate mappings
** Each iteration then looks to see if this mapping should be going *to* SFDC, *from* SFDC or *both* and performs the appropriate actions

No, this does not address keeping multiple keys from different SFDC objects in a single Drupal object but does allow the ability to have Drupal or SFDC *win* with certain fields in an environment where certain things should be synched only one-way.

As for UI for many-to-many, If each mapping form contained the ability to specify what *field* in the Drupal Object should be used as the key, then you could have multiple mappings per object with each mapping storing the necessary keys in unique fields.

Just a thought. :) Thanks!

EDIT: Oops. this was meant as a reply to #8

subscribe

Tracking for 7.x-2.x

In the Ubercart/Salesforce Integration module that I maintain, I pushed out code now that creates a Drupal object called "uc_order_purchaser", which is really the same as the "uc_order" object, in terms of what can be exported, and where it gets its data, but is not a duplicate, strictly speaking, because the name is different in the fieldmapping UI. I think to have a "uc_order" exported to two different Salesforce objects would be a bug.

As for the other way round (one Salesforce object, many Drupal objects), I am not sure. Are there circumstances in which that would be needed?

I'm involved on a multilingual D6 site build using content translation. As you are aware with content translation, multiple nodes are tied together as a translation set. So theoretically there's one SF object that maps to multiple Drupal nodes. There's a synch module that comes with the internationalization project. The proposed design at the moment is that someone will create the Drupal nodes in the translation set (not all data in the nodes will come from SF) then manually link one of them (the default language one) to the SF object. Then the synchronization module will handle pushing any updates detected from SF (via cron) to the translations. Obviously, data will only travel in one direction: SF -> Drupal.

I had tested what happens with linking all nodes in the translation set to the single SF object. Only one of the nodes gets updated. So nodes will only be manually linked to an SF object and the internationalization synch module will keep the SF-mapped fields in synch.

The design on the SF side is not set in stone at the moment so things may change. The client has been informed that there's only one-to-one mapping.

subscribe

there is some workaround about this for 7.x-2.x

it requires more work, testing

done
- allow multiple fieldmaps
- fieldmaps with the same object and same entity type and bundle have the same SF IDs, to have no SF duplicates.

to do:
- entity delete
- new sf_entity_salesforce_form for entities salesforce tab to deal with multiple fieldmaps
- fieldmaps weights for the order of execution
- and more

please feedback and support. thanks

Thanks for the patch. I've read through it but I think I'll have to test it in order to understand better how it works.

I wouldn't want to commit something with the potential for big shifts in architecture without consulting with Aaron and Kosta, the other maintainers, first, as well.

Also, I'm not sure if this is actually addressing what the original post was about.

I think that your patch is more of a feature addition than a bug fix, whereas Kosta's from #2 was more narrowly targeted at iterating through the fieldmaps for a particular Salesforce object and using whichever one satisfied the conditions for export rather than simply using the first one.

I know that Aaron had closed the other one-to-many issue (#785286: Provide ability to create one-to-many fieldmaps) as a duplicate, but I wonder whether it would be better to reopen that issue for exploration of this as a new feature, and this issue could simply be for handling the bug in the D6 sf_user & sf_node modules where they simply use the first fieldmap if there is more than one.

Aaron, Kosta, any thoughts? I'm moving this back to the 6.x queue for now.

of course all this it's feature.
but could be considered bug because multiple fieldmaps could be build, but they can't be used.

so any feedback for #1056630-18: Bug: sf_user allows creating many-to-many relationships between SF and Drupal objects, even as it assumes they're one-to-one? any thoughts? maybe others approaches/directions?

@vasike: What I'm saying though is that the original post was not a feature request, but a bug report.

I think that we should probably discuss the two in separate issues.

It'll be a few days unfortunately, before I would have time to give feedback on your patch, but I will try to get around to it in the next week or so.

more work on previous patch [1056630-18]. new one available. it's for d7.

new stuff:
- create entity saleforce subpages based on the entity fieldmaps
- break sf_entity_salesforce_form in 2 forms functions:
1. with the export based on the fieldmaps (not linked) selection
2. salesforce page based on a fieldmap linked

to do:
- more testing and bugfixing for those functions
- import stuff
- others

Note: please use ONLY on testing environments.

i just want to know if it's the right direction. please feedback
Thank you

New patch
More work on the Entity Salesforce Forms. It seems are done.

In my environment it works all. the Entity Salesform, Autoexport, Batch Import

The single (noticeable) change of the Arhitecture is the salesforce values for the the entity object ($entity->salesforce)

    [salesforce] => array(
        [fieldmap1] => stdClass Object
                (
                    [sfid] => XXXXXXXXXXXXXXXXXX
                    [name] => fieldmap1
                )
       [fieldmap2] => ... etc.
   )

where fieldmap1, fieldmap2, ... are the the fieldmaps names that are linked

so instead of

$entity->salesforce->sfid

we'll have

$entity->salesforce[$map->name]->sfid or $entity->salesforce[$name]->sfid

This is awesome, and sorely needed.
Thanks for doing all this work, vasike.

In order to keep our discussion on topic, I've re-posted your latest patch to #785286-4: Provide ability to create one-to-many fieldmaps
Let's take all feature request / task discussion for 7.x-2.x over there, and let's limit this thread to 6.x bug report discussion.

For the 6.x-2.x branch, it's too late to add such a major feature and architectural change into the current stable release.
If we can work it out on the 7.x-2.x branch, we may be able to get a backport into 6.x.

For now, let's try to mitigate bugs on 6.x without introducing any new features in order to forge a stable release.

Thanks, Aaron, for the direction. I thought also that it would be best to split the two.

So for clarity then, the last patch on *this* issue is actually #2, which may need a re-roll.

Is #23 for d7?

thanks (for everything, btw)

nico

yes. #24 too

Not to understand it wrong, with this patch I can work with SFaccount->DrupalUser<-SFOpportunity structure, right?

...and even using ie "username" as a common field for both accounts and opportunities?

thanks again

Well, sorry to have bothered with this for so long. My problem was that I kept on marking the update checkbox in the fieldmaps and that caused all the problems i was running into. By that, I was telling the web to send updates to several SF field that were read only... or required by SF and that is not the idea.... right?

Well, the module is great, but in drupal 7 has things like the one I described and if I can say, there are not enough tutorials or instructions for noobs like me.

Thanks again, and sorry.

nico

Although we are using only SF to Drupal sync, the above patch works quite well, small finetuning were needed to apply properly on the latest version.

FYI, people reading this some time later, patch 35 applies to 7.x-3.1. And it might be an idea to look at https://www.drupal.org/node/2694245 too.